用例是什么样子？

用例是什么样子？
为什么不同的项目组需要采用不同的用例编写风格？
在什么地方使用用例有利于做需求收集工作？
编写用例之前，需要做哪些准备工作？
为了帮助读者理解用例的概念，本书将在深入讨论用例具体细节之前，先对上述疑问进行简单解答。

一、用例是什么（梗概）

用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。用例描述了在不同条件下，系统对某一项目相关人员的请求所作出的响应。提出请求的项目相关人员被称为主执行者（primary actor）。主执行者通过发起与系统的一次交互来实现某个目标。系统对任一执行者所作出的响应，要保证所有项目相关人员的利益不受侵犯。根据执行者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列称之为一个场景（scenario）。一个用例是多个不同场景的集合。
虽然可以用流程图、顺序图、Petri网或程序设计语言来表示用例，但是从根本上说，用例是文本形式的。通常情况下，它们是作为人与人之间，尤其是没有受过专门培训的人员之间互相交流的一种手段。因此，简单的文本通常是编写用例的首选形式。
用例，作为一种编写形式，能够在项目组中激发对目标系统的讨论。项目组可以用用例来记录实际需求，当然也可以不用。另一个项目组可能会用用例来记录他们的最终设计结果。上述活动既适于支持大到整个公司系统，也适于支持小到软件应用程序的一个片断。重要的是，对于不同规模的系统，尽管各项目组对用例指定的严格程度和技术细节的深度要求各不相同，但是编写用例的基本规则却是相同的。
如果用用例来记录一个组织的业务过程，那么被讨论的系统（System under Discussion，SuD）是指组织本身。项目相关人员是指公司的股东、客户、供应商和政府管理部门。主执行者包含公司的客户，也可能还包含客户的供应商。
如果用用例来记录一个软件的行为需求，那么被讨论的系统是指计算机程序。项目相关人员是指使用该程序的人、拥有该程序的公司、政府管理部门和其他一些计算机程序。主执行者是指坐在计算机屏幕前的用户或者另一个计算机系统。
一个编写良好的用例应该具有很好的可读性。它由多个句子组成，所有句子都采用同一种语法形式——一个简单的执行步骤。通过执行这些执行步骤，执行者或者获得一定结果或者向另一个执行者传递信息。想学会如何阅读用例是很容易的，无需太多时间。
然而，要学会编写一个好的用例却不容易。编写者必须掌握三个概念，这三个概念适用于整个用例和用例中的每一个句子。初看起来，强调这三个概念的重要性显得有点多余，但要自始至终用好这三个概念却不是一件容易的事。一旦开始编写用例，就会感到困难重重。这三个概念是：
•范围（scope）：真正被讨论的系统是什么？
•主执行者（primary actor）：谁有要实现的目标？
•层次（level）：目标的层次是高，还是低？
下面将给出一些用例实例。用例的组成部分将在下一章介绍。首先，要记住下面总结的这些定义：
•执行者（actor）：任何具有行为的人或物。
•项目相关人员（stakeholder）：对被讨论系统（SuD）的行为有特定兴趣的人或物。
•主执行者（primary actor）：启动与被讨论系统的一次交互活动，从而达到某一目标的人或物。
•用例（use case）；规定被讨论系统行为的契约。
•范围（scope）：界定被讨论的系统。
•前置条件和保证（precondition and guarantee）：在用例执行之前和之后必须满足的条件。
•主成功场景（main success scenario）：一切顺利的情况。
•扩展（extension）：场景执行过程中出现的不同情况。
•扩展中的编号是指在主成功场景中不同情况发生时所处的执行步骤号码（例如，步骤4a和步骤4b是指主成功场景中步骤4的两种不同情况）。
•当一个用例引用另一个用例时，被引用的用例加下划线。
第一个用例描述了一个人准备通过万维网（Web）购买股票的情况。为了表示可以通过一次处理完成的目标，标记该用例处在“用户目标级”（user-goal level），并用“海平面”符号来表示。第二个用例描述了一个人设法获得汽车交通事故的赔偿金，这个目标要花费较长的时间，不能通过一次处理完成。为了表示这一特点，标记该用例处于“概要级”（summary level），并用“高出海平面”符号来表示。这些符号将在第5章中详细介绍，在内封前插页中已经总结了所有的符号。
第一个用例描述了一个人与一个程序（PAF）的交互活动，该程序运行在与万维网相连的工作站上。“黑盒”符号表示所讨论系统是一个计算机系统。第二个用例描述了一个人与一个公司的交互活动，用“建筑物”符号来表示公司。符号的使用完全可以根据个人的喜好来选择，但对范围和层次的标记却不是。
下图是用例1和用例2。

用例1：通过万维网购买股票

主执行者：购买者
范围：私人顾问/金融包（Personal Advisors/Finance package，简称PAF）
层次：用户目标
项目相关人员和利益：
购买者——购买股票，并希望所买股票能自动被加到PAF记录中。
股票代理商——希望得到全部的购买信息。
前置条件：用户已经打开PAF。
最小保证：有足够的登录信息，以便当出现问题时，PAF能够检测到问题，并要求用户提供更详细的信息。
成功保证：远程web站点认可此次购买事件；日志和用户记录被更新。
主成功场景：
1.购买者选择通过万维网来购买股票。
2.PAF从用户那里得到所用站点的名称（如E*Trade、Schwab等）。
3.PAF与该站点建立网络连接，并保持控制权。
4.购买者在该站点上浏览并购买股票。
5.PAF截取站点的响应信息，并更新购买者的记录。
6.PAF向用户显示更新后的记录情况。
扩展：
2a.购买者要使用一个PAF不支持的站点：
2a1.系统从购买者那里获取新建议，带有取消用例的选项。
3a.在设置过程中，网络发生故障：
3a1.系统向购买者报告错误，并建议他退回到前一步。
3a2.购买者或者退出此用例，或者重新再试。
4a.计算机系统崩溃或者在交易过程中被关掉：
4a1.（这时，我们该怎么办？）
4b.Web站点没有及时认可此次购买活动，而是把它推迟处理：
4b1.PAF把这次推迟事件记入日志，设置一个时钟，定期向购买者询问结果。
5a.Web站点没有返回关于购买情况的必要信息：
5a1.PAF把缺少信息的事件记入日志，要求购买者更新存有疑问的交易。

用例2：汽车交通事故索赔

主执行者：索赔者
范围：保险公司（MyInsCo）
层次：概要
项目相关人员和利益：
索赔者——获得尽可能多的赔偿金。
MyInsCo——赔偿尽可能少的赔偿金。
保险部门——确保事件处理