『转』用例建模指南
上一篇 / 下一篇 2009-04-28 14:25:36 / 个人分类:测试理论
用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的,后来被综合到UML规范之中,成为一种标准化的需求表述体系。用例的使用在RUP中被推崇备至,整个RUP流程都被称作 是"用例驱动"(Use-Case Driven)的,各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件,用例模型奠定了整个系统软件开发的基础。51Testing软件测试网;S ?-dtS@,?I]1Q!~g*C5n5M)@051Testing软件测试网tVAgkbR@
在 介始用例方法之前,我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能,在这种表述方式中,系统功能被分解到各个系统功能模块 中,我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式:51Testing软件测试网kY&gd.}i
1DL5K| ruSq0
.t!?r3t9P)D051Testing软件测试网7N#}T[W[
采 用这种方法来描述系统需求,非常容易混淆需求和设计的界限,这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑:系统需求应该详细到何种 程度?一个极端就是需求可以详细到概要设计,因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中,这种需求被称为"内部需 求",而对应于用户的原始要求则被称之为"外部需求"。
;DRV8N$kJa\0,p4b5qTu;e0功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环 境,从各项功能项入手,你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS文档中,我们往往需要另外一些章节来描述系 统的整体结构及各部分之间的相互关联,这些内容使得SRS需求更象是一个设计文档。
/P{[7JH.Z051Testing软件测试网Twe{LWD{ y+x1.1 参与者和用例51Testing软件测试网6E j8|%[:](c
a](jbx7y:z FB0从用户的角度来看,他们并不想了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,也就是被开发出来的系统将是如何被使用的,这就用例方法的基本思想。用例模型主要由以下模型元素构成:51Testing软件测试网*j?H?3FD;Qd~
- 参与者(Actor)
{7K7dX1W*b o0参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境。 - 用例(Use Case)
dz!E}Ar Z0用例用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 - 通讯关联(Communication Association)
~J|2uP0通讯关联用于表示参与者和用例之间的对应关系,它表示参与者使用了系统中的哪些服务(用例),或者说系统所提供的服务(用例)是被哪些参与者所使用的。
这大三种模型元素在UML中的表述如下图所示。
7}S+oZ2t051Testing软件测试网7r-skstrE0kV,X-n}l%lA$]'j0
uYE,XGF|%{,E0以银行自动提款机(ATM)为例,它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户,客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。
;oF@Ur051Testing软件测试网5w1U_JS4~-d@51Testing软件测试网%z N}0O"v
+PCh'Ky&?l9Nr2uj ~0通 讯关联表示的是参与者和用例之间的关系,箭头表示在这一关系中哪一方是对话的主动发起者,箭头所指方是对话的被动接受者;如果你不想强调对话中的主动与被 动关系,可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的,该信息流是缺省存在的(用例本身描述的就是参与者和系统之间的 对话),并且信息流向是双向的,它与通讯关联箭头所指的方向亳无关系。51Testing软件测试网;eRMXd\_7Y#]!t(V
51Testing软件测试网[Y&n%^3D5p^*}1.2 用例的内容51Testing软件测试网Q9E/V4~N Ty
51Testing软件测试网!?5z1c*{#CN2C ?用 例图使我们对系统的功能有了一个整体的认知,我们可以知道有哪些参与者会与系统发生交互,每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者 与系统之间的对话,但是这个对话的细节并没有在用例图中表述出来,针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的"提款" 用例可以用事件流表述如下:
~4q{B B uG!f H0W3b-T8z)?v0提款-基本事件流
;]&KD7~~D,tL051Testing软件测试网7M2U `:Bqm1. 用户插入信用卡51Testing软件测试网c%m:p5OmM*Cza
f~#DFGSF|02. 输入密码51Testing软件测试网j7Y-Hc)S ?
#NY2UTaVb03. 输入提款金额
)j"{ A1@|4KMu2d9T.yJ{01Cx6OsPY1O{04. 提取现金
"b-s8c*Y@051Testing软件测试网-WL-E%J1q&OMgB2U5. 退出系统,取回信用卡51Testing软件测试网LDm!@T p'd
B0yDPhb3G0但 是这只描述了提款用例中最顺利的一种情况,作为一个实用的系统,我们还必须考虑可能发生的各种其他情况,如信用卡无效、输入密码错、用户帐号中的现金余额 不够等,所有这些可能发生的各种情况(包括正常的和异常的)被称之为用例的场景(Scenario),场景也被称作是用例的实例(Instance)。在 用例的各种场景中,最常见的场景是用基本流(Basic Flow)来描述的,其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的"提款"用例,我们可以得到如下一些备选流:
8Q ] P2|AY051Testing软件测试网 Ix_)l$Q2ETeJ提款-备选事件流
"[5uR\@&d/N7MDBu0Pdav[K_+t0备选流一:用户可以在基本流中的任何一步选择退出,转至基本流步骤5。
K0Fq EsH!cS FYJ01qoW vDL5K:d1F0备选流二:在基本流步骤1中,用户插入无效信用卡,系统显示错误并退出信用卡,用例结束。
/`M"OU.B:~K0[WE\bVUTb0备选流三:在基本流步骤2中,用户输入错误密码,系统显示错误并提示用户重新输入密码,重新回到基本流步骤2;三次输入密码错误后,信用卡被系统没收,用例结束。
8w U#@8Bn,R051Testing软件测试网yC4nd]…51Testing软件测试网 UlG0u4Se
S[*r2?Nl)Bq HO/c7S0通过基本流与备选流的组合,就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候,就是要尽可能地将所有可能的场景都描述出来,以保证需求的完备性。51Testing软件测试网+n$C Rm8Z9dXfJ
4N$M JZw~ ]01.3 用例方法的优点
(o `.~.X+KkH051Testing软件测试网!OJG8~+?5q$pDa"g用 例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法中,我们把被定义系统看作是一个黑箱,我们并不关心系统内部是如何完成它所 提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor),这些使用者与被定义系统发生交互;针对每一参与者,用例方法又描述 了系统为这些参与者提供了什么样的服务(抽象成为Use Case),或者说系统是如何被这些参与者使用的。所以从用例图中,我们可以得到对于被定义系统的一个总体印象。51Testing软件测试网J&Rf8z0u-q,qk
#^ALy@#~Z)f7_0与传统的 功能分解方式相比,用例方法完全是从外部来定义系统的功能,它把需求与设计完全分离开来。在面向对象的分析设计方法中,用例模型主要用于表述系统的功能性 需求,系统的设计主要由对象模型来记录表述。另外,用例定义了系统功能的使用环境与上下文,每一个用例描述的是一个完整的系统服务。用例方法比传统的 SRS更易于被用户所理解,它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。
-C/n8Q9YQ1W4p051Testing软件测试网-l2{7F8a6k在RUP中,用例被作为整 个软件开发流程的基础,很多类型的开发活动都把用例作为一个主要的输入工件(Artifact),如项目管理、分析设计、测试等。根据用例来对目标系统进 行测试,可以根据用例中所描述的环境和上下文来完整地测试一个系统服务,可以根据用例的各个场景(Scenario)来设计测试用例,完全地测试用例的各 种场景可以保证测试的完备性。51Testing软件测试网v"^,tI5hK d]
/bZr6R3O;El S0
-]3y{*_.A*K0 |
51Testing软件测试网-l/{t _ p:_
|
51Testing软件测试网v$@+jvLJH
51Testing软件测试网L6J?]l
2. 建立用例模型51Testing软件测试网/u!u.a&HA u L/YQ0D
;E @4L)qB],j/NL@0使用用例的方法来描述系统的功能需求的过程就是用例建模,用例模型主要包括以下两部分内容:51Testing软件测试网7oc3rt3f!SI
- 用例图(Use Case Diagram)
1rAZ8| t}n0确定系统中所包含的参与者、用例和两者之间的对应关系,用例图描述的是关于系统功能的一个概述。 - 用例规约(Use Case Specification)
4q Ta b{GMy9~0针对每一个用例都应该有一个用例规约文档与之相对应,该文档描述用例的细节内容。
在用例建模的过程中,我们建议的步聚是先找出参与者,再根据参与者确定每个参与者相关的用例,最后再细化每一个用例的用例规约。
B-IL @E#E;s5l:Z"iGv051Testing软件测试网7U;FI3K}l0s&uB1V1?+bl2Y/X051Testing软件测试网 uHC/`$N所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲,参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手:51Testing软件测试网F,mgP;sq:aX&v]I
- 系统开发完成之后,有哪些人会使用这个系统?
- 系统需要从哪些人或其他系统中获得数据?
- 系统会为哪些人或其他系统提供数据?
- 系统会与哪些其他系统相关联?
- 系统是由谁来维护和管理的?
&X4Sx[j0这些问题有助于我们抽象出系统的参与者。对于ATM机的例子,回答这些问题可以使我们找到更多的参与者:操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。
!VHuEP051Testing软件测试网d%V{yl8H3w.J IUBHpN+i3v W0
2@+Uhb6Xm4P02.1.1 系统边界决定了参与者51Testing软件测试网K s"Bnb
3vzn|a6h0参与者是由系统的边界所决定的,如果我们所要定义的系统边界仅限于ATM机本身,那么后台服务器就是一个外部的系统,可以抽象为一个参与者。51Testing软件测试网3U)~+N*R/mn#l;s%QShi
51Testing软件测试网)n,x$j0f-J)Yj;a51Testing软件测试网J&B[a*MSI3DCr
9K ~6Z1rG)w*xBNw0如果我们所要定义的系统边界扩大至整个银行系统,ATM机和后台服务器都是整个银行系统的一部分,这时候后台服务器就不再被抽象成为一个参与者。
`kj;k[%j9z0