三、 用例
一个用例就是与参与者（actor）交互的，并且给参与者提供可观测的有意义的一系列活动的集合【大象——Thinking in UML，P47】。 所谓用例，就是一件事情，要完成这件事情，需要一系列活动；而做一件事可以有很多不同的方法和步骤，也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称之为用例场景，一个场景就是一个用例的实例【大象——Thinking in UML，P47】。 用例：用例定义了一组实例，其中每个实例都是系统所执行的一系列操作，这些操作生成由特定主角可以观测的值【大象——Thinking in UML，P47】。 用例只是在需求阶段和系统分析阶段会用到，在设计阶段就不会再使用了。 用例的一个特征是“不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。【大象——Thinking in UML，P40】” 这说明没有人参与的需求一定有别的事物在发出启动的动作，应当找到这个事物，这个事物就是一个参与者，它可能是另一个计算机系统、一个定时器或一个传感器【大象——Thinking in UML，P40】。 在查找参与者的过程中，可以询问一下问题以帮助确定参与者【大象——Thinking in UML，P41】：
谁负责提供、使用或删除信息？ 谁将使用该功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其它还有那些系统将需要与该系统进行交互？1.需求阶段
1.1.需求获取
1.1.1.业务用例
用于业务建模阶段【大象——Thinking in UML，P61】。 业务用例是用于描述客户现有业务的，那么业务用例面对的问题领域就是没有将来的计算机参与的、目前客观存在的业务领域【大象——Thinking in UML，P61】。 相应的它的参与者就是业务主角，站在业务主角的立场上看到的边界是业务边界而非系统边界【大象——Thinking in UML，P61】。 业务用例说明与系统用例说明的格式十分相似，但是在设计范围上有些分歧。 业务用例的设计范围是业务操作。它是这个组织外部的业务参与者，实现与业务组织相关的业务目标。 让我们查看这个业务用例的 RUP 定义： “业务用例从一个外部的，增加值的角度来描述一个业务过程。为了给这个业务的涉众创造价值，业务用例是超越组织边界的业务过程，很可能包括合作伙伴和供应商”。 这个定义标识了一些重要点，比如：
一个业务用例描述的是业务过程，而不是软件系统过程。 一个业务用例为涉众创造价值，这些涉众要么是业务参与者要么是业务工作者。 一个业务用例可以超越组织的边界。有些构架师对于这一点有非常严密的态度。许多业务用例确实超越来组织的边界，但是有些业务用例仅仅关注于一个组织。我稍后将在这篇中给出一些例子。 让我们也看看 Podeswa 的书 UML for the IT Business Analyst 中对业务用例的定义： “业务用例：业务过程是描述这个业务的具体工作流的；一次涉众与实现业务目标的业务之间的交互。它可能包含手工和自动化的过程，也可能发生在一个长期的时间段中。” 这个定义表明了通过实现业务目标创造价值的观点。它通过把一个业务过程描述成一个可能包含手工和自动化过程的具体工作流来详述 RUP 的定义。这个定义还指出，工作流可能发生在一个长期时间段中。所有的这些都十分的重要。
1.1.2.业务用例实现 也称为业务用例实例，用于业务建模阶段。 从字面上理解，业务用例实现就是业务用例的一种实现方式。一个业务用例可以有很多种实现方式，它们的关系可以类比编程上的接口和实现类的关系，同一个接口可以有多个实现类【大象——Thinking in UML，P62】。
1.2.需求分析
1.2.1.概念用例 在实际情况中，概念用例很少被使用。 概念用例获取业务用例中的核心业务逻辑，这些核心业务逻辑揭示了业务模式，成为业务架构的重要指导。同时，概念用例还是从业务用例到系统用例过渡时非常重要的指导。虽然概念用例不是必需的，但是对于复杂业务来说，缺少了它，系统用例的产生就会显得突兀和生硬，基本上是拍脑袋的出来的结果【大象——Thinking in UML，P63】。
2.系统分析
2.1.系统用例 系统用例的含义：系统用例是软件系统开发的全部范围，系统用例是我们得到的最终需求。如果说业务用例是客户业务视角的话，系统用例将采用系统的视角来看待了【大象——Thinking in UML，P64】。 系统用例就是通常我们所说的用例，如果不是特别强调，用例等同与系统用例【大象——Thinking in UML，P64】。
2.2.用例实现 用例实现完整的叫法是系统用例实现。
3.主角获取 【大象——Thinking in UML，P52】
主角是位于系统边界外的； 主角对系统有着明确的期望和明确的回报要求； 主角的期望和回报要求在系统边界之内。
4.用例获取
这些问题对获取用例来说已经足够了【大象——Thinking in UML，P52】。
您对系统有什么期望； 您打算在这个系统里做些什么事情； 您做这件事的目的是什么； 您做完这件事希望有一个样的结果。并且应当确保【大象——Thinking in UML，P53】：
一个明确的有效目标才是一个用例的来源； 一个真实的目标应当完备的表达主角的期望； 一个有效的目标应当在系统边界内，有主角发动，并且有明确的后果。
5.用例特征 【大象——Thinking in UML，P49】
用例是相对独立的； 用例的执行结果对参与者来说是可观测的和有意义的； 用例必须有参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例； 用例必然是以动宾短语形式出现； 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至是部署单元。
6.用例规约 【http://www.ibm.com/developerworks/cn/rational/r-usecase-atm/index.html， 用例建模指南】 描述用例规约。 应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务， 让我们 对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述 ――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：
简要说明 (Brief Description)简要介绍该用例的作用和目的。
事件流(Flow of Event)包括基本流和备选流，事件流应该表示出所有的场景。
用例场景 (Use-Case Scenario)包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
特殊需求 (Special Requirement)描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
前置条件 (Pre-Condition)执行用例之前系统必须所处的状态。
后置条件 (Post-Condition)用例执行完毕后系统可能处于的一组状态。 用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的 简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的 系统行为，序列图适合于描述基于时间顺序的消息传递。
7.用例粒度 【大象——Thinking in UML，P309】 在业务建模阶段，用例的粒度以每个用例能说明一件完整的事情为宜，及一个用例可以描述一项完整的业务流程。 在概念建模阶段，用例的粒度以每个用例能描述一件完整的事件流为宜。 在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。
8.用例间关系
8.1.业务用例、系统用例比较 业务用例模型与系统用例模型之间主要有三点重大不同之处：设计范围、白盒测试与黑盒测试，以及业务操作者。 （1） 范围 在前面的部分中，我借助 Alistair Cockburn 的处于“水平线”上面、下面，或正好处于“水平线”的规定对设计范围进行了讨论。 业务用例着重于业务操作。它们表示实现业务目标的业务中的具体工作流。业务过程可能涉及手工和自动过程，并且在一段长期的时间内进行。 系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。 （2） 业务角色 那么业务角色是什么？在系统用例图中，您只让参与者与用例进行交互。但在业务用例图中，您可以让业务参与者和业务角色与业务用例进行交互。 业务参与者是业务之外的人。它可以是一个角色或其他组织实体。例如，在刑事审判系统中，业务参与者可以是证人、嫌疑犯、外部的政府机构，例如健康服务，或业务实体，例如，业务资信咨询机构。 业务角色是业务内部的某个人或某个部门。在刑事审判系统中，业务角色可以是治安人员、法官、检察官，或假释官。当您实现了一个业务用例，并且创建了时序图和/或 通信图来显示业务参与者、业务角色，和业务实体如何协作执行业务用例时，您将会把业务角色从业务用例模型转入业务分析模型，并且加入所需的额外业务角色来提供业务用例功能。
