`

用例的类型与粒度

阅读更多

在正式讨论如何获取用例之前,笔者觉得有两个问题还是先解释清楚为好,这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑,也是最难掌握的。一个是各种用例类型之间的区别和用法,另一个是用例的粒度。
在正式讨论如何获取用例之前,笔者觉得有两个问题还是先解释清楚为好,这对正确获取用例有很大帮助。这两个问题也是初学者最为困惑,也是最难掌握的。一个是各种用例类型之间的区别和用法,另一个是用例的粒度。
先说说用例类型的问题。
用例类型,有的资料翻译为版型,英文原文是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 use case realization推知。

 

再来说说用例的粒度问题。

粒度是令人迷惑的。比如在ATM取钱的场景中,取钱,读卡,验证账号,打印回执单等都是可能的用例,显然,取钱包含了后续的其它用例,取钱粒度更大一些,其它用例的粒度则要小一些。到底是一个大的用例合适还是分解成多个小用例合适呢?这个问题并没有一个标准的规则,笔者可以给大家分享的经验是根据阶段不同,使用不同的粒度。在业务建模阶段,用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。例如取钱,报装电话,借书等表达完整业务的用例,而不要细到验证密码,填写申请单,查找书目等业务中的一个步骤。在用例分析阶段,用例的的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是,这个阶段需要采用OO方法,归纳,抽象业务用例中的概念模型。例如,宽带业务需求中有申请报装,申请迁移地址用例,在用例分析时,可归纳和分解为提供申请资料,受理业务,现场安装等多个业务流程中都会使用的概念用例。在系统建模阶段,用例视角是针对计算机的,因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。例如,填写申请单,审核申请单,派发任务单等。可理解为一个操作界面,或一个页面流。在RUP中,项目计划要依据系统模型编写,因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。

上述的粒度划分方法笔者是用相对比较具体化的一些依据来说明。实际上,用例粒度的划分依据(尤其是业务用例)最标准的方法是一个用例的粒度是否合适,是以该用例是否完成了参与者的某个目的为依据的。这个说法比较笼统,也比较难以掌握。,举个例子,某人去图书馆,查询了书目,出示了借书证,图书管理员查询了该人以前借阅记录以确保没有未归还的书,最后借到了书。从这段话中能得出多少用例呢?请记住一点,用例分析是以参与者为中心的,因此用例的粒度以能完成参与者目的为依据。这样,实际上适合用例是:借书。只有一个,其它都只是完成这个目的过程--这里讨论的用例指的是业务用例--这个例子是比较明显的能够区分出参与者完整目的的,在很多情况下可能并没有那么明显,甚至会有冲突。读者可以从自己实际的情况去找出这种例子。以后的文章中笔者会做一些讨论。

但是上述的粒度选择并不是一个标准,只是在大多数情况下这样的粒度选择是比较合适的。笔者的意思也不是告诉读者上述哪一种是最好的,而只是把一些常用的比较,划分方法告诉读者,期望的是帮助读者在工作实践中自己总结出一套适合自己的方法来。现实情况中,一个大型系统和一个很小的系统用例粒度选择会有较大差异。这种差异是为了适应不同的需求范围。比如, 针对一个50人年的大型项目应该选择更大的粒度,如果用例粒度选择过小,可能出现上百甚至几百个业务用例,造成的后果是需求因为过于细碎和太多而无法控制,较少的用例有助于把握需求范围,不容易遗漏。而针对一个10人月的小项目应该选择小一些的粒度,如果用例粒度选择过大,可能只有几个业务用例,造成的后果是需求因为过于模糊而容易忽略细节。一般来说,一个系统的业务用例定义在多于10个,少于50个之间,否则就应该考虑一下粒度选择是否合适了。

不论粒度如何选择,必须把握的原则是在同一个需求阶段,所有用例的粒度应该是同一个量级的。这应该很好理解,在描述一栋建筑时,我们总是把高度,层数,单元数等合在一起介绍,而把下水道位置,插座数量等合在一起介绍。如果你这样介绍一栋楼:这栋楼有10层,下水道在厨房东南角,预留了15个插座,共有5个单元,听众一定会觉得云山雾罩,很难在脑子里形成一个清晰的影像。

如果对上面两个问题读者还有疑惑,不用着急,在以后的文章中应该会逐步加深理解。

预告:下一篇文章将通过一个例子,阐述获取用例的一般方法和如何判断用例的粒度是否合适。

Q&A

--------------------------------------------------------------------------

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

A:这个问题很好,用例的粒度总是在这样左也可右也可之间难以决定。对这个问题来说,我的观点是业务用例应当用“管理用户”或“维护用户”作为合适的粒度,而增,删,改,查则在作为系统用例。我的理由是:
增删改查不能做为一个完整的业务来理解。作为一个管理业务,数据只有先增,才会有改,才会有删。增删改查结合起来才能完成actor的管理目的,只删或只增加都不是业务的全部。这篇文章后来我又补充了一条粒度的判断标准,可以到http://coffeewoo.itpub.net/去看,是否是一项完整业务,要看actor的目标,而不是事情是否完整。这个例子中,actor的目标是为了增加一个用户吗?是为了删除一个用户吗?都不是,而是为了管理用户,这个目标包括了用户这个实体的整个生命周期。

再讨论深一些,如果业务要求对用户除了增删改查,还有别的要求,例如权限升级,用户在组织机构中复杂的关系变更,用户与外部系统的交互....实际的情况可能会更多,那么,如果将每个都作为一个业务用例,很容易造成一个结果,这些原本与用户这个实体紧密关联,共同组成用户实体生命周期的业务,被割裂成多个独立的业务,因为定义了多个用例(请参看本人第一篇中的用例特征第一条)。要知道,在RUP中,用例驱动的含义是,一个用例就是一个分析单元,设计单元,开发单元,测试单元甚至部署单元。相信读者都知道,把紧密关联的业务分成多个独立部分去实施是高成本的,高风险的。

另外,为什么我要说在系统用例阶段要把增,删,改,查又分出来呢?原因在于,系统用例的目的是为了将actor的业务用计算机模拟出来。我们都知道,一般情况下,增,删,改,查对一个actor来说是不会同时发生的,每次actor只会完成其中的一个行为。分开来,有利于详细分析模拟这一行为的细节而不至于混淆。另一方面,对WEB应用来说,针对数据的增,删,改,查等,很容易形成所谓的“模板”,增加用户用这个模板,增加其它基础数据可能也用同一个模板,无非是操作的数据(实体)不同而已。因此,在很多情况下,这些模板是可以复用的。对这个例子来说,在系统用例阶段,我们可以用“管理用户” include “增加用户”来表示这个实现关系,同时,让“增加用户”,“增加XX数据”等等用例来继承自一个抽象出来的“增加数据”用例,这样,可复用的模板体现在“增加数据”用例上,而具体业务,则体现在“增加XX数据”上。实际上,这也是一种OO思想的体现。

只有一个查询是比较特殊的,查询一般不一定只局限于一个actor,也不一定局限这个用例,一般都是所谓的综合查询,是可能跨用例的。所以根据实际情况,查询可以作为一个业务用例出现。

分享到:
评论

相关推荐

    基于用例的需求过程

    此步骤中的粒度通常为EBP(基本业务流程)级别。 #### 六、需求分析详解 **需求分析**阶段则专注于查找系统目标、确定系统功能以及实现系统功能等环节: - **查找系统目标**:识别SuD的服务对象(即系统用户),...

    软件测试用例

    这些方法有助于我们更有效地设计和优化测试用例,特别是在自动化测试场景下,更细粒度的用例划分有利于自动化脚本的编写和执行。 综上所述,测试用例设计应全面覆盖表单测试、逻辑判断和业务流程三个层次,结合多种...

    自动化测试异常处理及用例管理.doc

    测试用例的粒度应适中,每个用例对应一个独立的操作和预期结果。 6. 优先级和重要性:为测试用例分配优先级和重要性,有助于在资源有限的情况下优先执行核心业务或关键功能的测试用例。在自动化测试中,这尤为重要...

    用例图介绍-用例图入门

    用例可以根据其描述的详细程度分为粗粒度用例和细粒度用例两种。 1. **粗粒度用例**:描述系统的整体功能和主要业务流程,通常用于系统级别的需求分析和规划阶段。它帮助团队理解系统的总体结构和业务流程的大致...

    软件测试-基于用例的需求过程

    - **适用范围**:这种方法主要用于管理类软件项目的开发过程中,但也可以根据实际情况调整应用于其他类型的软件项目。 #### 三、需求过程模型 ##### 1. 需求过程模型概述 需求过程模型主要由两个过程域组成:业务...

    大象——Thinking in UML 配套光盘内容

    用例的类型与粒度 - **用例的类型**:主要包括主用例、支持用例和支持用例扩展。主用例代表系统的主要功能,而支持用例则是为了增强或补充主用例的功能而存在的。 - **用例的粒度**:指用例描述的详细程度。良好的...

    UML 用例图的PPT

    UML(统一建模语言)是软件开发中用于可视化、构造和文档化的标准工具,其中用例图是一种重要的图表类型,它描绘了系统与外部用户,即活动者之间的交互。用例图提供了一个高层次的视角,展示了系统的核心功能及其与...

    Patterns_for_Effective_Use_Cases

    - 子用例(Sub-Use Case):可重用的、更细粒度的用例,可被其他用例包含。 3. **用例的写作技巧**: - 描述清晰:用简洁明了的语言,避免技术术语,让所有利益相关者都能理解。 - 实例化:通过具体实例来解释...

    UML建模语言和Rational Rose工具.ppt

    - **用例粒度**需要适中,过小可能导致描述过于琐碎,过大则可能涵盖过多细节,难以管理。 - **用例的描述**通常包括结构化和半结构化的文本,以及UML图形,两者结合使用能提高描述的准确性和完整性。 - **用例的...

    第6章 面向对象分析.pdf

    - **分析类**是概念层次上的内容,其粒度通常较大,可能包含较少的操作和属性。分析类主要用于描述系统的核心概念和职责,而不涉及具体的实现细节。这些类可以通过概念性的属性和关系来定义其行为。 #### 面向对象...

    OA系统项目开发.docx

    - **用例粒度**: 决定一个用例包含多少功能点,通常建议每个用例的基本路径不超过十步。 - **用例命名**: 建议以动词开头,描述一个具体的动作或功能,如“管理商品”。 - **扩展点**: 在用例的基本路径之外,记录...

    lattices:Haskell的细粒度晶格图元

    描述中提到"用于构建和操作晶格的细粒度库",意味着该库可能包含了一系列的函数和类型类,这些函数和类型类允许用户创建自定义的晶格类型,执行常见的晶格运算,如join和meet,以及进行更复杂的推理和转换。...

    软件需求管理计划

    需求管理计划 ...4.7 需求基线:指通过了评审的软件需求,通过建立这样一个基线,受控的系统需求成为进一步软件开发的出发点,对需求的变更被正式初始化、评估,其表现形式为用例描述的集合。 ......

    UML业务建模

    - **业务用例的粒度**:合适的粒度有助于清晰地界定需求范围。一般情况下,一个用例应描述一项完整的业务流程。 #### 七、UML工具使用 - **Rose工具**:一种常用的UML建模工具,支持多种类型的图表绘制,如类图、...

    软件工程之软件功能测试方法

    本篇文章将深入探讨几种常见的功能测试方法,包括由简到繁的测试设计原则、测试用例与数据的分离、功能点全覆盖以及界面功能控件全覆盖。 首先,由简到繁的测试设计原则强调从简单的测试描述开始,逐步细化为具体的...

    使用UML进行项目开发.pdf

    为确保用例粒度适当,应避免将其细化至系统活动或交互步骤层面,以免混入技术语言。正确的用例描述应保持业务语言的纯粹性,确保需求分析的准确性和完整性。 #### 设计阶段:类图与序列图构建系统架构 进入设计...

    cpp-doctest最轻的特性丰富的C单个header的测试框架

    1. **子测试**:允许在测试用例内部创建子测试,提供更细粒度的测试。 2. **测试用例重试**:可以设置测试用例的重试次数,以处理偶尔失败的情况。 3. **测试过滤器**:通过命令行参数,可以指定运行特定的测试...

Global site tag (gtag.js) - Google Analytics