用例分析——案例研究 - IT 观察者随笔

Table of Contents hide

用例是一种需求捕获和文档技术，可以用纯文本编写，以叙述方式描述使用系统的参与者的操作和交互。最后，系统的功能应该满足利益相关者使用系统的目的。

在使用文本记录用例描述之前，我们可以先使用用例图突出显示参与者使用系统的目的。通过图形表示，您可以从鸟瞰图快速了解整个画面。定义系统的范围（系统边界）并确定支持使用系统功能或服务的参与者（称为用例）的主要目标。

用例图有利于团队沟通，这是人类的天性：使用图形通常比通过文字进行沟通更好。

在团队对系统的整体外观和感觉有初步了解和共识后，需求分析师打开椭圆形用例，并以正确且易于阅读的格式描述参与者与系统之间的对话过程。

逐步提高用例的精度，从简单到复杂。不要一开始就陷入复杂的细节中，以免在错误的设计和描述上投入过多的精力。用例图有助于从简单到复杂，并减少不必要的谬误。

从图中可以看出，本系统的设计范围是“在线订书系统”，使用该系统的主要参与者之一是“在线客户”，使用该系统的参与者的目的是“订书”。

“订单簿”是系统的用例，参与者是“在线客户”。在确定了参与者的目的后，我们会在文字叙述中记录目的的细节，即记录参与者之间的交互以及系统操作以达到目的。这称为用例描述。

下表描述了一个简单的“订单簿”用例。

该用例由软件巨头 Jacobson 于 1992 年首次发布，对现代面向对象技术产生了相当大的影响。此外，由所谓的“三位朋友”——Booch、Jacobson 和 Rumbaugh 共同制定并经过 OMG 审查的 UML（统一建模语言）规范已被列为主要标准规范的重要组成部分。

以下是几家软件巨头对用例的定义。

在《统一建模语言用户指南》一书中，给出了用例的定义：

从上面的讨论中，我们可以得到与用例相关的特征：

用例是用自然语言描述的叙述文档（如英语叙述）。一般来说，一个用例不涉及图形或编程语言语法（如java）来描述。
用例中描述的场景正是参与者期望通过与系统的交互和通信来完成（获得）他们的目标（Goal）。
例如，“购买商品”正是消费者消费的目的：
“消费者结账购买的商品，收银员记录购买的商品并收取货款。一旦完成，消费者就会带着商品离开。”
一个用例可以有一个正常场景，也可以有多个异常场景。正常场景描述了参与者与系统交互的正常过程；而在与系统交互的过程中，如果考虑到异常的发生，根据情况的复杂程度，可以用“正常场景下的“替代路径”来描述”，也可以用另一种方式来描述复杂异常的场景。
系统将提供一系列功能与参与者进行交互，但参与者不需要知道系统中发生了什么或如何去做，系统只需将结果发送回参与者即可。因此，对于参与者来说，系统是（或一组用例）一个黑盒子。
用例的描述强调系统应该做什么（what to do），而不是如何做（how to do）。因此，在用例的描述中不应该描述实现的细节。
演员直接来到操作系统。在用例图中，虽然参与者被表示为“简笔画”图标，但参与者不一定是真人。参与者也可能是一个外部系统，它可能需要从这个系统中获取一些信息。