用例允许在设计或考虑中捕获系统的需求，描述这些系统提供的功能，并确定系统对其环境的要求。
UML规范，例如 [UML 2.5 RTF – Beta 2] 提供了几种略有不同的用例定义。我从这些部分编译了下面的定义。
用例是一种行为分类器(behaviored classifier)，它指定由一个或多个主体(subjects)执行的有用功能的完整单元,用例与一个或多个参与者(actor)协作,对于完整的用例，它产生了一个可观察到的结果对于每个主体的参与者或其他利益相关者都有一定的价值。
UML规范要求：“ 必须始终为UseCase完成此功能，如果执行后主体处于不再需要进一步输入或操作并且可以再次启动UseCase的状态，或处于错误状态。“
这个要求的问题是它不考虑 扩展用例 和包含用例。扩展用例本身可能不一定有意义。包含的用例是提取到单独用例的一些常见部分。要求产生可观察的结果似乎也不适用。
这一需求的问题在于，它不考虑扩展用例(extending use cases) 和包含用例(included use cases)。扩展用例本身不一定是有意义的。包含用例是提取到单独用例的一些常见部分。这似乎也不适用于要求产生一个可观察的结果。
用例功能总是有用也是值得怀疑的：“ 每个UseCase指定了主体提供给用户的有用功能单元。 ”
“UseCase可以应用于任何数量的主题。”对于每个用例，期望至少有一个主题是合理的，否则用例的定义是毫无意义的。与此同时，在UML规范中使用UseCase类描述允许用例没有关联的主题。
虽然“ 本节中指定的关键概念是Actor，UseCases和主体 ” ，但用例的其中一个定义也提到了“ 主体的其他利益相关者 ” 。如果添加了“利益相关者”，它们应该作为一个单独的概念包含在UML规范中。。
UML规范直到UML 2.5要求用例功能是由参与者发起的。在UML 2.5中，这被删除了，这意味着当系统功能由系统本身启动时，可能会出现一些情况，同时仍然为参与者提供有用的结果。例如，系统可以通知客户订单已经发货，调度用户信息清理和归档，请求其他系统的某些信息等。
而且，直到UML 2.5之前的所有UML 2.x规范都声明用例“ 是根据参与者的需求定义的 ” 。这个句子已从UML 2.5中移除，因为有些参与者可能自己没有需求。
命名用例
UML规范没有提供用例名称的准则。唯一的要求是每个用例都必须有一个名称。我们应该遵循用例定义，为系统执行的功能单元提供一些名称，该系统为参与者提供了一些可观察和有用的结果。用例名称的示例：
-
进行购买
-
下订单
-
更新订阅
-
转移资金
-
雇用员工
-
管理帐户
符号
用例通常显示为包含用例名称的椭圆。
用户注册用例
用例的名称也可以放在椭圆下面。
转账资金使用案例
如果显示一个主题（或系统边界），则用例椭圆在视觉上位于系统边界矩形内。注意，这并不一定意味着主题分类器拥有所包含的用例，而仅仅是用例适用于该分类器。
用例没有标准关键字或原型。用例可以用一个自定义的原型在名称上面显示。作为分类器，用例具有 属性(properties)。用例属性列表 – 操作(operations) 和属性(attributes) – 可以在用例名称下方的用例椭圆内的隔离区中显示。
具有属性和操作的用例
将用例用户登录定型为“身份验证”
带有扩展点的用例(extension points)可以在用例的一个隔间中列出扩展点
注册用例与扩展点注册帮助和用户协议
一个用例也可以用标准的矩形符号表示，在矩形的右上角有一个椭圆图标，并为其要素提供可选的单独列表隔离区。
使用标准矩形表示法为分类器显示注册用例
抽象用例(Abstract Use Case)
包括UML 2.5在内的所有UML 2.x规范都没有提及，定义或解释抽象用例。UML 1.x规范提到“抽象用例的名称可能用斜体表示”，但从UML 2.0开始，这个句子从UML规范中删除，没有任何解释。
句子被删除的一个原因可能是因为用例是一个分类器，任何分类器都可以是抽象的（名称用斜体表示），所以很明显它也应该适用于用例。
另一方面，由于该句子被删除，UML 2.5没有提及抽象用例，甚至没有提供一个抽象用例的例子，这可能意味着他们希望所有用例都是具体的，而不是抽象的。在这种情况下，在UML规范中明确解释这种情况是合理的。
假设用例可以是抽象的和运用恰当的定义为分类器， 抽象用例是是没有完整的声明（不完整）和（“典型的”，如UML规范所说）不能被实例化的用例。抽象用例旨在用于其他用例，例如作为泛化关系的目标 。我希望“抽象用例的名称可以用斜体表示”在UML 2.5中仍然适用，因为它是在UML 1.x中指定的。
Web用户身份验证用例是 由Login，Remember Me和Single Sign-On用例专门设计的抽象用例。
当UML 2.4规范描述 包含用例之间的关系时，他们解释说：“基本用例中留下的内容通常不完整”，但出于某种原因避免将其称为抽象用例。一般来说，这意味着包含用例总是抽象的。
银行ATM交易用例成为 抽象用例，由于包括客户身份验证用例。
虽然UML规范避免了这样做，但通常找到定义包括用例作为抽象用例或基本用例的源代码。尽管我们可能认为包含用例总是抽象的，但包含的用例可能是抽象的或具体的。令人惊讶的是，有些来源 – 我不能同意 – 提供完全相反的解释，包括（基本）用例通常是“具体”，而包含（“添加”）用例通常是“抽象的”。
为了增加混淆，还有其他来源将抽象用例定义为抽象级别描述的用例（业务用例，有时称为基本用例），而不是系统用例。
业务用例(Business Use Case)
尽管对业务建模的支持被声明为UML的目标，但UML规范没有提供业务用例的概念。
业务用例在Rational Unified Process（RUP）中被引入，以支持业务建模以表示在建模业务中执行的业务功能，流程或活动。业务用例应该对业务参与者产生可观察价值的结果。
业务用例定义了当业务参与者请求用例时，业务中发生了什么，它描述了完整的工作流或业务流程，它产生所需的结果或需要业务参与者。
业务用例在RUP中用椭圆形用例表示，并且右下方有斜线表示。
业务用例个人登记入住
有两种替代方法来命名业务用例。用例可以从业务参与者的角度来命名 – 表达角色的目标或者角色的需求 – 或者从业务本身的角度来看 – 通过给业务参与者提供业务流程或服务的名称。
业务用例– 候选人申请工作
“ Apply for Job”业务用例表达了候选业务角色的目标。从业务角度来看的另一个名字是雇佣员工。
业务用例– 业务服务，向客户提供膳食
在这种情况下，业务用例是根据业务流程或服务命名为-业务供应膳食给客户。从参与者视角的角度来看，另一个名字是吃饭。
通过比较餐厅的业务用例图，您可以看到这两种方法之间的其他差异 。
通过比较餐馆业务用例图的例子，您可以看到这两种方法之间的其他差异
描述用例行为(Describing Use Case Behaviors)
用例行为(behaviors) 可以用自然语言文本（不透明行为）来描述，这是目前常见的做法，也可以通过使用UML 行为图(behavior-diagram) 来表示特定行为，如
-
活动(activity)，
-
状态机(state machine)，
-
交互(interaction)。
用例的行为也可以通过使用用例及其与者作为输入其部分(part)的分类器的协作(collaboration)来间接描述。
使用哪些技术取决于用例行为的性质以及目标读者。这些描述可以结合使用。
UML工具应该允许链接行为与描述的用例。用例可以在 标为用例或uc（缩写形式）的框架中呈现。框架的内容区域可以用描述用例行为的不同种类的UML图来表示。
用例搜索项目作为框架，显示相关搜索项活动图
下面使用UML 2.5表示法将用例与活动表示的行为进行绑定的另一个示例。
购买票用例拥有“购买票”活动表示的行为。
下面的购买票活动图示例描述了购买票用例的行为
使用活动图描述的购买票据用例行为示例。
用例的执行是紧急行为的发生。实现用例的分类器的每个实例必须按用例描述的方式运行。
用例之间的关系(Relationships Between Use Cases)
用例可以使用以下关系进行组织：
-
泛化(generalization)
-
关联(association)
-
扩展(extend)
-
包括(include)
用例之间的泛化(Generalization Between Use Cases)
用例之间的泛化关系与类之间的泛化相似-子用例继承父用例的属性和行为，并可能覆盖父用例的行为。。
泛化表现为具有大空心三角箭头的实线，与 分类器之间的泛化相同 ，从更具体的用例指向到抽象用例。
Web用户身份验证用例是 由Login，Remember Me和Single Sign-On用例专门设计的抽象用例。
用例之间的关联(Association Between Use Cases)
用例只能 二元关联。
指定同一主体的两个用例不能关联，因为它们各自单独描述了系统的完整用法。
,
