什么是用例?
用例是一种 需求捕获和文档技术,可以用纯文本编写,以叙述方式描述使用系统的参与者的操作和交互。最后,系统的功能应该满足利益相关者使用系统的目的。
在使用文本记录用例描述之前,我们可以先使用用例图突出显示参与者使用系统的目的。通过图形表示,您可以从鸟瞰图快速了解整个画面。定义系统的范围(系统边界)并确定支持使用系统功能或服务的参与者(称为用例)的主要目标。
用例图有利于团队沟通,这是人类的天性:使用图形通常比通过文字进行沟通更好。
在团队对系统的整体外观和感觉有初步了解和共识后,需求分析师打开椭圆形用例,并以正确且易于阅读的格式描述参与者与系统之间的对话过程。
逐步提高用例的精度,从简单到复杂。不要一开始就陷入复杂的细节中,以免在错误的设计和描述上投入过多的精力。用例图有助于从简单到复杂,并减少不必要的谬误。
![](https://www.cybermedian.com/cn/wp-content/uploads/sites/6/2022/01/0sCrOVMqKvi_Yk8kA.png)
从图中可以看出,本系统的设计范围是“在线订书系统”,使用该系统的主要参与者之一是“在线客户”,使用该系统的参与者的目的是“订书”。
“订单簿”是系统的用例,参与者是“在线客户”。在确定了参与者的目的后,我们会在文字叙述中记录目的的细节,即记录参与者之间的交互以及系统操作以达到目的。这称为用例描述。
下表描述了一个简单的“订单簿”用例。
![](https://www.cybermedian.com/cn/wp-content/uploads/sites/6/2022/01/1lmDvfJrF1N7HnKtG0Yoqxg.png)
用例的起源
该用例由软件巨头 Jacobson 于 1992 年首次发布,对现代面向对象技术产生了相当大的影响。此外,由所谓的“三位朋友”——Booch、Jacobson 和 Rumbaugh 共同制定并经过 OMG 审查的 UML(统一建模语言)规范已被列为主要标准规范的重要组成部分。
以下是几家软件巨头对用例的定义。
- “用例是描述参与者使用系统完成事件的过程序列的叙述性文档”[Jacobson92]。
- “用例是一组场景(事件流),与系统的共同使用目的相关”[Fowler97]。
- “用例是参与者(通常是人,但也可能是外部实体,例如另一个系统)在系统内执行以实现特定目标的一系列操作”[Rosenberg99]。
- “一个用例是一个参与者(通常是一个用户,也可能是一个外部实体,比如另一个外部系统),在与内部系统的交互中为实现特定目标的一系列动作”。
在《统一建模语言用户指南》一书中,给出了用例的定义:
- “用例描述了一组序列,其中每个序列代表系统外部事物(其参与者)与系统本身(及其关键抽象)的交互”。
- “用例描述了一系列序列,每个序列都表达了系统外部事物(参与者)与系统本身(及其关键抽象)之间的交互。”
从上面的讨论中,我们可以得到与用例相关的特征:
- 用例是用自然语言描述的叙述文档(如英语叙述)。一般来说,一个用例不涉及图形或编程语言语法(如java)来描述。
- 用例中描述的场景正是参与者期望通过与系统的交互和通信来完成(获得)他们的目标(Goal)。
- 例如,“购买商品”正是消费者消费的目的:
“消费者结账购买的商品,收银员记录购买的商品并收取货款。一旦完成,消费者就会带着商品离开。” - 一个用例可以有一个正常场景,也可以有多个异常场景。正常场景描述了参与者与系统交互的正常过程;而在与系统交互的过程中,如果考虑到异常的发生,根据情况的复杂程度,可以用“正常场景下的“替代路径”来描述”,也可以用另一种方式来描述复杂异常的场景。
- 系统将提供一系列功能与参与者进行交互,但参与者不需要知道系统中发生了什么或如何去做,系统只需将结果发送回参与者即可。因此,对于参与者来说,系统是(或一组用例)一个黑盒子。
- 用例的描述强调系统应该做什么(what to do),而不是如何做(how to do)。因此,在用例的描述中不应该描述实现的细节。
- 演员直接来到操作系统。在用例图中,虽然参与者被表示为“简笔画”图标,但参与者不一定是真人。参与者也可能是一个外部系统,它可能需要从这个系统中获取一些信息。