用例是一种描述需要的主意,可是都对编写用例经常会遇见的难点

  编写了那么多的用例,那用例到底是干嘛的?用例为领导者指明应送交给用户的体系效用。用例的标题指明主执行者的要求,同时系统也必须协理这几个要求,而用例描述则印证了系统须要怎么着效果以及将提供什么样服务。

概要


用例(Use
Case)是一种描述系统须要的不二法门。运用用例这种艺术来叙述系统须要称之为用例建模。用例也是UML规范中的一种规格的急需表明形式,其中比较知名的RUP(Rational
Unified Process)就是以用例来驱动的。

值得一提的是,尽管RUP被认为是一种重量级的软件管理进程,而进一步多的软件开发起始使用高效方法来响应变幻无常的急需转变。不过用例作为一种描述要求的方法,其眼光和方法论对我们解析要求照旧有自然的扶植。

从表达方式上看,用例相对时序图、流程图等急需表明格局,越发面向对象和面向设计。平时景况下,用例相比便于让从未受过专业培训的人口承受。用例可以用作一种跟用户照旧行外人员陈述必要的方式。

        
在一伊始接触用例的时候,UML课程中提及过用例的先行级以及用例版本号等其它细节,对于那一个音讯的集中可以称之为规划表,而规划表在类型支付进程中,能够卓殊简单的对那张表展开审核和操作。其它,可以对各样用例进行评估,指定用例开发组,以及对每种用例,每一个版本的行事展开跟踪。

用例是什么样

用例是一种描述必要的措施,用例描述了在不一样的尺度下,系统对参加者的哀求做出的响应。用例日常通过一个参预者(Actor)(谁?)向系统做出请求,系统依据参预者的请求(要做什么?),在不相同的尺码下,执行某一行为种类(系统怎么满意?)。各种作为系列可以称之为一个场景(Scenario),一个用例包蕴多少个现象。场景也得以称为用例的一个实例(Instance)。

        
在编写用例的经过中,出错是那个正常的,而发现错误和会改良错误的这一步时万分健康的。那么,什么地方会时时出标题?怎么修改?那是一个很首要的环节,十九章就付给了当用例紧缺系统、主执行者、过多的用户接口、过低的对象级别等难题应运而生的时候,相对应的化解办法。

用例的重组

正式的用例应该包含:用例名、概述、范围、级别、主参加者、项目有关人口和利益、前置条件、最小保障、成功保险、触发事件、主成功景观、扩大场景和有关信息等等。

逐一组成部分的含义如下:

  • 用例名(Title):<用例目的>
  • 概述(Goal in Context):<要描述用例流程和目标>
  • 范围(Scope):<安排范围>
  • 级别(Level):<大意、用户目的、子作用>
  • 主执行者(Primary Actort):<主执行者或角色>
  • 类型相关人士和好处(Stakeholders and
    Interests):<品种相关人和关键利益列表>
  • 停放条件 (Precondition):<早已达标的原则>
  • 微小保险(Minimal Guarantees):<用例必须执行的音讯>
  • 打响保证(Success Guarantees):<目的成功时举行的消息>
  • 接触事件(Trigger):<接触了用例的轩然大波>
  • 主成功场景(Main Success Scenario):<目的成功的要紧步骤>
  • 扩展(Extensions):<大概现身的别的步骤,包蕴十分情形>

        
固然本书第二有些情节不多章节也少,可是都对编写用例日常会遇上的难题,提供了相应的消除办法和理论依照。由于大多例子都以专属于案例的,全都搬到笔记里并不合乎,由此,只留下了有些理论的根据和原因,并未进行详细讲解。

用例的格式

用例可以用于不一样的目标,如:

  • 叙述要求,便于和用户沟通须求。
  • 讲述业务的进度,指点项目开销。
  • 笔录须要钻探进度,并最终文档化。

今非昔比的编撰目标导致了用例在编辑进程中有可能出现不相同的基本点。

在区其他协会景况也或许造成用例书写的不平等。比如在一个特大型的开发品种组里,就须求严峻的根据用例范例举行描述,而在一个袖珍的交换频仍的项目组里,则可以利用一种相比较简单来讲述格局。

上文提到的是相比广泛的组成部分。事实上,用例的格式并没有硬性规定,在要求时得以增减里面的新闻。具体用例须求包括什么样新闻,有差其余派系。有趣味可以查阅相关资料,这里不举行讲。

一句话概括: 您的用例不是自己的用例,唯有切合的用例才是最好的

正文紧要观点均来自于《编写有效率例》(Writing Effective Use Cases
)笔者是 Alistair Cockburn。有趣味的可以读一下原著。

        
因而,很快的进去了本书的第三局地“对劳累编写用例的人的指示”。看到标题应该就足以猜到这一部分是给“光干活不留神细节的人”的人看的。哈哈,比如小编。上次写一分课后作业,写了好半天,回头一翻,竟然还写错内容了!真真是白白忙活。编写用例也是一模一样的,与其花很多时间捉摸商讨,不如,先跳出来好雅观看,看看本身恐怕会遇见的难点,再进来内部探讨有关题材。

须求和用例

用例用于表述要求,可是有两点要小心的:

  • 用例确实是必要。
    不必要将用例转化成其余的必要表明形式。用例可以完整的叙说系统要求。

  • 用例不必然是独具需求。
    用例只是急需的一局地,用例并不描述外部接口、数据格式、业务规则、品质、可维护性等须要。

        
在一起来学用例的时候,大家先是个接触的便是用例图,后边才是拔取的语言描述,大家总认为,学工科的东西,表述的越不难越好,不过,用例却应该是一篇散文,易于阅读,但是又要拥有美感。那么五个人在学习,肯定不是所有的人都喜爱读书的,所以,让外人能够看得下去,第三个点就是让难题短小而切题,并且从头开始,用一条主线贯穿始终。跟写作文一样,用例是是要起因经过结果的,并且依照宗旨。而且,为了让难点短小精悍,就要选用动词短语来定名用例,然后从接触事件始于,至到对象落到实处只怕被裁撤,用例才大概终止。其他的连锁的细节过多,就不一一演说了,不过,不说不意味着第一,所有的细节都以相当首要。顶层的小说轶闻,只是一有的,而后续需要不停开展的传说,如同写传说背景相似,轶事的始发不仅仅是一个初始,照旧一个又一个的传说。而且写传说的时候不恐怕跑题,一定要记得自身原来的业务范围和业务边界,即便这些界限某种程度上来说特别的模糊,可是却又不得不去分别。

用例组成部分


用例名(Title)

用例名用于标识一个用例,便于集中和读书。

平整:使用主动语态的动宾短语来叙述。

相似景色下,提议使用主动语态的动宾短语来叙述用例的对象。如:“查找商品”“参预购物车”。在某些情状下,如要求更纯粹的意味出一个用例,可以加入定语举办修饰,如:“用户清除购物车”“管理员清除购物车”

规则:以主加入者为对象开展描述。

用例的叙说必要以主到场者为目的开展描述,如可以利用“支付订单”(以主参加者为对象),而不是“收取订单花费”(以种类为目的)。

【举例】

用例1:购买商品
……

范围(Scope)

用例的限定能让大家对系统的界线和议论的要求有一个基础的语境,不相同的筹划范围可能会招致我们须求研讨的参预者、场景都会不同。一言以蔽之,就是为大家谈论的体系划定一个范围规定大家谈谈的壁垒。

例如我们要琢磨一个用户的下单行为。假使以所有公司为限制,其项目的连带人口为用户、第三方服务者(如快递等)。但一旦以种类为限制,其体系相关人口还应当蕴涵集团内部的系统管理员、客服等。

故此,在编写用例时要求搞了解,大家的用例的限量是何许,那样可以对用例啄磨的难点达成一个共识。

意义范围

在谈论用例的设计范围时,要求先确定系统的效果界定。Cockburn在《编写有作用例》里面推荐了一个规定效用限制的法子“内/外列表”

主题
查询商品
打印订单
加入购物车
订单管理
跟踪物流路径

规定功用范围的补益是总而言之。如,系统外部已经有了一个打印订单的系统,如若不强烈区分系统的功效范围,部分开发人士有大概会对打印订单成效举行设计和落实。而实际上,那些功用是不要求规划的。

旗帜明显了意义范围后,还足以肯定系统的实践人士。如上边的例证,打印订单系统将用作“打印订单”用例的赞助执行者。

设计范围

设计范围是在效用界定规定了后来做的。设计范围指的是大家在编写用例时琢磨难点的边际和对象。我们在用例里面说的范围(Scope)借使没有非常表明指的就是安排性范围(而不是意义范围)。

上面来看一个例证,ECom集团打算做一个ESys的系统,系统之中包涵了ESubSys等四个子系统。

图片 1

规划范围的深浅

要是以ECom为统筹范围来琢磨用例,我们关怀的是用户对公司的急需是何等,集团以什么的样式满意用户的请求。假设有外部公司,则还要考虑外表公司与商家之间来回的事体是哪些。

设若以ESys为设计范围来研究用例,大家更关怀用户向系统倡导的伸手和系统对请求的响应。同时,借使以ESys做限定的时候,集团内部的员工也成了用例的实施者,大家还应该考虑职工对系统的呼吁。

规定用例范围,能很好的对其我们要探究的题目是何许,界定大家谈论难题的界定,给用例一个言语环境。

平整:设计范围是一个简短的专出名称。

用例的限制应当是一个概括的专用名词,简单说雅培(Abbott)下用例研讨的限定界线。如,上边的例子中范围可以直接用“ECom”“ESys”“ESubSys”来表示。

【举例】

用例1:购买商品
限制:电商系统
……

主执行者(Primary Actort)

主执行者是系统相关人口中,请求系统做出响应的人或物。主执行者是对系统请求的发起者,但是主执行者可以不是一贯操作系统的相干人口

内部一种情景下是主执行者通过另一个种类操作相关人士对系统举行操作。如,客户致电客服询问相当订单的风貌。客户并没有直接通过系统进行查询。

另一种景况是定时触发任务。如客户愿意系统定时执行一个职务,那么最后实施系统的连锁人士是系统本人。

虽说识别出主执行者很重点,然而在有些时候主执行者也没那么主要

在编排用例时,识别出主执行者,可以从执行者角度出发,充足梳理系统须求。我们还足以主执行者的性状来统筹系统的并行。如下表,主执行者概括表:

名称 概况:技能和背景
客户 了解电脑软件的操作,对基本的系统软件有操作经验。
管理员 熟悉通用的软件,能解决做日常的系统维护。但是不懂编程。
经理 能进行简单的电脑操作,对界面呈现要求高,缺乏多步骤操作耐心。
…… ……

在多数情景下,大家起始编制用例起先后,主执行者就变得没那么主要了。例如,当大家在安顿查询订单用例时,无论是管理员、老董、客服甚至是此外的配合社职位,在查询订单这么些用例上并没有特意的分歧。这些时候,主执行者具体是何人已经不根本了。

规则:用例的主执行者可以是执行者恐怕执行者脚色。

在上述意况下,大家会将有些主执行者一般化的法子,成立一个“角色-执行者对应表”。在上述用例里,我们将社团者、高管等一般化为一个操作角色——订单管理者。大家在描绘用例时,以角色当作主执行者即可。

【举例】

用例1:购买商品
主执行者:用户
限制:电商系统
……

概述(Goal in Context)

概述紧要用以描述用例的对象,约等于用户必要已毕的目的。

平整:使用自然语言描述。

尽心尽力利用当然的言语解说用户要落成指标时,用户会做什么样业务。

平整:描述用例落成如何,而不描述系统步骤。

只需求讲领悟用例要求形成的作业即可,那里不必要描述系统步骤或然用户的具体操作流程。

如:“用户拔取一件必要购买的货色后,可以将商品进入购物车,然后在购物车里面提交订单。用户也足以不须求插足购物车,直接购买选中的商品。”概述并不须求描述具体的系统操作,在此间并不曾描述“点击进入购物车按钮”等系统的操作细节。

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并开发货款。不包罗管理员处理订单。
范围:电商系统
……

相关人员和好处(Stakeholders and Interests)


概述

品类的有关人口是指对系统有特定利益的参加者。相关人口不必然是人,也可以是一个表面系统、一个团社团等。

由此能成为门类有关人口的有大概是:

  • 选用或关心系统的外部人或物。
  • 用例的主执行者。
  • 用例的协助执行者。
  • 系统里头执行者。
  • 被规划的系统本人。

主执行者

主执行者是倡议执行用例的相关人士。

赞助执行者

帮助执行者是为被设计的系统举行服务的的外部执行人士。协助执行者可以是其它一个系统、也得以是一个人或公司。如,一台打印机,为系统打印各类票据。再如,快递公司,为系统提供快递服务,并提供物流音信。

中间执行者

里头执行者是在系统内部关心系统利益的连带人口。

被设计的种类

被设计的序列自己有时候对协调也是有一定利益的。

对此有关人口,有几点须要评释:

  1. 系统相关人士有或许不直接和连串互相。
    譬如说,公司决策者,只怕不会亲自操作系统,然则对系统运行的风貌和其他运营数据却是格外关怀的。这一个有关人士在系统操作步骤中大概不会冒出,可是用例依旧必要描述对这一部分相关人士的补益。

  2. 关切“沉默的”相关人口。
    系统相关人员有时并不是那么明白。比如上文提到的,有些相关人士并不是直接操作系统的人手。往往是那一个“沉默”的相关人口考虑不足,正是系统中期必要频仍变更的原因之一。

平整:相关人口和好处用以对应列表的点子书写。

使用”<相关人员>:<利益>“的艺术,描写相关人口和其关怀的便宜。

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并开发货款。不包罗管理员处理订单。
界定:电商系统
……
种类有关人口和利益:
用户:希望通过系统下订单购买需求她须求的货物。
系统:记录用户购买的订单,以便给订单管理员处理。
……

级别(Level)

在编辑用例进度中,大家偶尔会切实描述一个用户的需要(如用户购买商品),有时候会讲述一个连串的求实职能(如用户登陆),有时候会讲述一个流水线(如购置商品并获取商品的流程)。在编制用例的时候,知道用例所处的岗位,对我们编辑和领会用例有很大的扶植。

小编们将用例级别从总到分划分成了多个层次:概要、用户目的、子成效。

用户目标

用户目标是指主执行者使用系统可望获取的靶子。用户目标是大家编辑用例的机要。用户目标描述了主执行者通过系统“做一件什么事”,以及做完那件事后“用户能取得什么好处”

用户目的应该是主执行者一回执行系统拿到利益的经过。所以,不是一回施行所能已毕的对象,可能用户不可以博取利益的急需不或者称之为用户目的。

如,购买一个货物的流水线,这些从下订单到快递必要几天的进度,所以不大概称为一个用户目的。再如,用户登陆,用户登陆并不能够收获什么利益,所以也无法称为一个用户目的。用户下单这几个操作,可以当作一个用户目的。

概要

概要层次可以分包多少个用户目的,概要目的实施周期比用户目的更长,能够是一个几天、几个月甚至更长的经过。概要目标有多少个目标:

  • 为用户目标提供一个运行的语境。如,明确用户目的是在座谈下单流程。
  • 展现用户目的之间的上下相继。如,明确下单用例、查询快递用例、签收订单用例之间的左右相继。
  • 作为几个用户目的的汇总。如,下单流程汇总了多少个有关的用户目标。

子功能

子成效层次是用户目的在履行进度中会执行到的靶子。如,三遍登陆,两回订单打印等。也有只怕存在三个用户目的共用一个子职能,如搜寻商品、查找订单等。

子作用用例的存在是为着用户目的用例增添可读性而留存的。在实质上编写进程中,不到迫不得已,不要设计子功效层出用例

规则:层次唯有多个挑选:概要、用户目的、子效率。

用例的层次只好是差不离、用户目的、子作用多个里面的一个层次。

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并支付货款。不包罗管理员处理订单。
限制:电商系统
级别:用户目的
品种相关人士和好处:
用户:希望通过系统下订单购买必要他索要的货物。
系统:记录用户购买的订单,以便给订单管理员处理。
……

置于条件(Precondition)

内置条件是大家在用例执行之先前时代望必须成功的尺码。在用例编写进度中,可以不对该规则举行反省和议论。如,“下订单”无法不借助于“用户已经登陆”本条放手条件。

平整:前置条件必须是用例执行前大家期望一定成功的原则。

要谨防将这几个并不是必须规范的口径写入前置条件。如,撤消订单并不重视于用户下单成功,事实上,用户可以将下单不成事(例如支付退步)的订单废除掉。而订单下单是不是成功这么些标准是索要在用例里面对那一个规则进行反省并履行不通过动作的。

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并付出货款。不包括管理员处理订单。
限定:电商系统
级别:用户目的
品种相关人士和利益:
用户:希望经过系统下订单购买须求她须求的货物。
系统:记录用户购买的订单,以便给订单管理员处理。
置于条件:用户已经登陆系统。
……

小小的保险(Minimal Guarantees)

小小的保障是用例执行无论是或不是成功都会被实践的保障。即使,用例无论执行成功与否,最小有限协助总会被实施。可是,最小有限支撑愈来愈多的是为用例执行破产意况下,为用例相关人士提供的功利保障。最小保障可以有多个。

一个大面积的很小保障例子是“系统将用户执行记录日志”,即使用例执行破产,用户的操作也将会被记录到日志里面。

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并付出货款。不包含管理员处理订单。
范围:电商系统
级别:用户目的
品种相关人士和好处:
用户:希望经过系统下订单购买须求她须要的货色。
系统:记录用户购买的订单,以便给订单管理员处理。
停放条件:用户已经登陆系统。
细微保障:系统记录用户操作进程的日志。
……

事业有成保障(Success Guarantees)

得逞保险是指用例执行成功后,用户所能拿到的补益保障。相关人士的补益能不能得到保险,是用例执行成功的判断条件。成功保险可以有三个。

比如说,在下订单用例中,用户下单成功后,必须保险“订单被创立,并付出到后台处理。”

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并开发货款。不包蕴管理员处理订单。
范围:电商系统
级别:用户目的
项目有关人口和好处:
用户:希望通过系统下订单购买须要她索要的货品。
系统:记录用户购买的订单,以便给订单管理员处理。
嵌入条件:用户已经登陆系统。
小小保障:系统记录用户操作进程的日记。
中标保险:

  1. 系统成功创建用户订单。
  2. 系统接到用户支出货款。
  3. 用户的订单操作和付款消息被记录成日志。
    ……

接触事件(Trigger)

接触事件是指用例启动的风浪,用例将通过接触事件,开始一步一步执行。

平整:触发事件是跟系统相互的第四个操作。

以用户下单用例为例子,用户决定要购买商品后,在系统中搜索商品并下单。那么“用户决定要选购商品”并不或者作为用例的接触事件,事实上,用户更系统的互相是从“查找商品”开始的,所以“用户查找商品”才是用例的接触事件。

咱俩谈论用户跟系统互相时,还应该小心大家谈谈的连串的限量。尤其是当主执行者不是直接操作软件系统的风貌时,更应当了解系统范围。如,“用户致电客户老总下单”那样的情况下,大家的系统范围并无法限定在软件系统范围内,那是系统范围是商店。所以,“用户致电客户总经理”跟大家系统相互的首先步,所以可以变成“触发事件”

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并支付货款。不包蕴管理员处理订单。
范围:电商系统
级别:用户目的
项目有关人口和好处:
用户:希望通过系统下订单购买必要他索要的商品。
系统:记录用户购买的订单,以便给订单管理员处理。
放置条件:用户已经登陆系统。
微小有限支撑:系统记录用户操作进程的日记。
事业有成保险:

  1. 系统成功创建用户订单。
  2. 系统接到用户支出货款。
  3. 用户的订单操作和给付消息被记录成日志。
    接触事件:用户选中须要购置的物料。
    ……

主成功场景(Main Success Scenario)

主成功场景是用例从接触事件开始,一步一步执行,最后知足用例利益的步子集合。

主成功场景应该包括以下新闻:

  • 八个执行者之间的竞相。如,用户提交了订单。
  • 为保证主成功景色得以持续的认同。如,系统确认用户密码。
  • 主成功场景推进进程中的内部变化。如,系统扣除用户账户余额。

举行步骤应该有一对简易的条条框框:

平整:使用简易语法。

应用简单语法结构:

主语……谓语动词……前置短语……宾语。

例如:

系统……扣除…一定数量的…用户账户余额。

平整:准确描述执行者之间的切换。

推行步骤必要规范描述步骤执行进程中,执行者之间的切换。如,“用户致电客户代表”,我们得以明白步骤已经从用户切换来了客户表示。

不过,有时候在执行者明确的动静下,也有只怕不会产出在句子中。如,“用户输入密码”,大家也得以知道那一个手续的实施者已经从用户切换来了系统。我们不用接纳“用户向系统输入密码”那种冗余的叙说形式。

平整:从系统外去讲述步骤。

不应有从系统内部,只怕全部以系列角度去考虑而已。而应当从系统外去讲述步骤。

假设从系统之中去描述步骤,或者会写成:

读取用户密码,确认密码正确。

设若在系统外部去讲述步骤,则公布成:

用户输入密码。
系统确认用户密码正确。

规则:展现进度向前推移。

一对小的步骤只好落成少数做事,有时候那几个干活儿并不大概很好的讲述进程在迈入推移。如,“用户点击了确定按钮”。那几个手续并无法很好的叙述过程在前进推移,用户的真人真事目标是登陆系统,随着用户登陆系统,用例步骤可以继续往下举办。

平整:彰显执行者的意图,而不是动作。

执行者寻常是经过操作系统执行一个动作的,在描绘用例时,不难将用户动作和实施者的来意搞混。

例如:

  1. 系统须要用户输入身份音信
  2. 用户输入用户名密码
  3. 用户点击确定按钮
  4. 系统确认用户地方新闻
    ……

用例过多描述了系统操作界面和用户的动作,如“需要用户输入身份消息”,那个并执行者的企图,而只是一个互动动作。

大家可以减去描述用户动作的步调,将用例改成:

1.用户输入用户名密码
2.系统确认用户身份信息。

平整:包蕴合理的移位集。

叙述步骤的时候,并不一定需要各种步骤之包括一个平移。依据需要可以将部分活动集合在一个手续里面。

如:

用户下单成功。系统发送短信给用户,告知用户订单号。

本条手续也得以描述成五个步骤:

用户下单成功。
系统发送短信给用户,告知用户订单号。

用例的描述格局以简要,有效为主,有时候并不拘泥于具体的方法。事实上很多开发协会都形成了友好的用例编写规范。

规则:步骤描述成功的现象,而毫不突显只怕的破产。

主成功场景的步骤描述的是成功的步骤。例如:

系统判断用户信息是否正确。

要是这么编写步骤,大家就要连续考虑“若是判断正确……”“若是判断战败……”。然则在主成功场景的步子中,是不显示失败的步子的。所以,须求将步骤改成

系统确认用户信息。

只要一旦系统验证战败如何是好?那有的音讯放到伸张里面描述。下文种详细表明,那里不举行。

规则:当步骤不总是实施是,可以投入时间限制。

一大半景色下,步骤是一步接一步执行的。可在少数时候,可以这么讲述:

当用户选择直接提交订单时,……。

规则:一个步骤可以提到三个有关人口。

大家偶尔要求经过一个系统向另一个体系倡导一个推行动作,可以写成:

用户通过系统向物流系统获取物流数据。

规则:可以屡屡实践一个或三个步骤。

偶尔用户会反复实践其中一个或多个步骤,那时候需求在步骤中增添一定的叙说。如:

1. 用户查找一个商品
2. 用户将商品加入到购物车中。用户可以重复1~2步,直至用户完成商品选购。
3. 用户选中购物车中的商品下单
……

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并付出货款。不蕴含管理员处理订单。
范围:电商系统
级别:用户目的
品种相关人士和好处:
用户:希望通过系统下订单购买必要他索要的货色。
系统:记录用户购买的订单,以便给订单管理员处理。
停放条件:用户已经登陆系统。
微小保障:系统记录用户操作进度的日记。
事业有成有限协理:

  1. 系统成功创制用户订单。
  2. 系统接到用户支出货款。
  3. 用户的订单操作和付款消息被记录成日志。
    接触事件:用户选中需求购买的物品。
    主成功场景:
  4. 用户输入须要购买的货物规格和数目。
  5. 系统确认商品规格和多少。
  6. 系统来得购买价格。
  7. 用户完结付款。
  8. 系统确认收款后,提醒用户下单成功。
    ……

扩展(Extensions)

增加是主成功场景的道岔,是指主成功场景在部分其余标准下会形成的不等动作。请小心,使用“增添”而非“万分”或“错误”,事实上增加包罗了中标和挫败三种大概的口径。其主干的逻辑是,在执行主成功景观时,要是系统……(检测到意外),那么,……(做一些作业)。

普遍的有大概出现恢弘的情景如下:

  • 另一种可能出现的中标路径。(如:用户设置了机动登陆)
  • 执行者操作错误。(如:用户输入的密码错误)
  • 执行者无其余操作。(如:用户输入超时)
  • 必要系统确认的场所。(如:系统确认用户余额充裕)
  • 接济执行者或其余有关人口反馈失利。(如:打印机执行打印错误)
  • 检测到个中错误,并或然暴发外部可知的结果。(如:写多少战败)
  • 根天品质目的不达标。(如:系统超越15秒没有再次回到成功)

在那些境况出现后,我们应该在壮大中讲述这个场景处理形式,然后回到主成功场景只怕退出用例。

扩张是针对主成功景色的,所以大家写编写伸张的时候,必要用数码来注脚伸张的照应关系:

主成功场景如下:

 ……
2 系统确认用户密码正确。
……

伸张如下:

……
2a 密码输入错误:……
2b 密码输入超时:……
……

一旦是各个步骤都只怕会接触的扩张,可以用”*“号来表示,如:

……
* 用户关闭登陆页面:
……

可能一旦是一些步骤触发的共有条件,可以加上步骤来表示,如:

……
2-5* 用户关闭登陆页面:
……

规则:从系统检测到的角度去描述伸张条件。

增添条件应该是系统能检测到的规格,而不是发生了什么。如,用户忘记密码了,系统不可以检测到用户是还是不是密码依旧是任何的怎么来头。从系统检测到的角度去描述,系统只好检测到用户输入错误的密码依然用户输入超时。

平整:合理化合并伸张条件。

增添条件实在无需枚举出所有的大概出现的场合,和客体的限制内,大家得以将一些增添条件合并成等价项。判断等价项,有多少个正规:

  • 系统可以检测到的基准。
  • 系统必须做到的规则。

诸如,用户输入密码的步调里面,用户可以淡忘密码输入错误,也足以手误输入错误大概别的的或者性,这个条件都以系统不得以检测的口径。首先,将那几个原则转换成系统可以测试的尺度:密码输入错误。转换后,所有标准就足以统一成一个了。

在来看一下系统能够完结的条件,如,密码输入错误、用户名错误、用户名不存在等,我们系统的拍卖都以“提醒用户名或密码错误或不存在”。那时候可以将规范合并成“系统检测到用户名或密码输入错误”

还有一种情况,假使在低层级(如子成效级别)用例已经完全描述了扩展,那么在其高级别(如用户目的级别)用例,能够绝不再行冗余描述。比如,在子功能级别用例“保存数据”里面早已全部描述了封存进程中只怕出现的种种扩张条件,那么在其上司用例里就足以毫不描述了。

【举例】

用例1:购买商品
主执行者:用户
概述:用户选中商品后,通过系统下订单购买商品并开发货款。不包罗管理员处理订单。
界定:电商系统
级别:用户目的
品种相关人口和利益:
用户:希望经过系统下订单购买须要她需求的货色。
系统:记录用户购买的订单,以便给订单管理员处理。
放置条件:用户已经登陆系统。
细微保险:系统记录用户操作进程的日志。
事业有成保障:

  1. 系统成功成立用户订单。
  2. 系统接到用户支付货款。
  3. 用户的订单操作和给付消息被记录成日志。
    接触事件:用户选中要求购置的物料。
    主成功场景:
  4. 用户输入需求购买的商品规格和数目。
  5. 系统确认商品数量。
  6. 系统来得购买价格。
  7. 用户完毕付款。
  8. 系统确认收款后,提醒用户下单成功。
    扩展:
    2a: 数量不足:
    2a1: 指示用户数量不足,再次回到步骤1等待用户重新输入。
    4a: 用户余额不足:
    4a1: 提醒用户余额不足,需要用户更换付款形式。
    4a2: 用户更换付款情势继续付款。
    4b: 用户支出密码错误:
    4b1: 指示用户余额不足,提醒用户重新输入密码。
    4b2: 用户重新输入密码,达成开发。
    4b3: 用户延续输入3次错误密码,系统冻结用户付款账户12个小时。
    4c: ……
    ……

总结


用例还是能以用例图的不二法门来表示。本文紧假诺由此用例的关怀点和用例的整合来探索一下一种须求的叙述方式,所以就不对用例图举行介绍了。有趣味的读者可以自动参考其他资料通晓。

在火速开发特别受到青眼的前些天,用例那种相对较“重”的须要分析和公布情势越来越少的被人利用。当是大家透过商量用例的关注点和分析方法,其广大思考照旧得以借鉴到我们常见的需求分析当中的。