用例是能够被行为者感受到的，由系统所执行的一系列完整动作（功能），表示行为者与系统间的交互，为相关的行为者提供其所期望的服务。用例的用途是在不揭示系统内部构造的前提下定义连贯的行为。系统的功能是通过行为者使用用例来实现的。
用例是由一组用例的实例组成的，每一个用例的实例称为场景（Scenario），例如，用例“签署购房合同”的一个实例（场景）是：张小明刚刚签订了一份15年的银行按揭贷款购房合同，购买了120平方米的房子。场景是用户使用系统的一个实际的、特定的事件流集，一个用例的多个场景就覆盖了所有的正常与异常的事件流，如图4－9所示。场景帮助我们验证用例是否能满足客户提出来的功能需求并驱动测试用例的编写。实际上，在分析人员与客户的交流中，客户所描述的通常是一些场景，而分析人员需要讨论、归纳不同的场景对应的系统功能，并由此分类总结出完整的用例。
图4－9 一个用例中包含的事件流与场景
在UML中用例用一个包含用例名称的椭圆图标来表示，用例的名称可以直接给出，或者连同该用例所在的系统边界（即包或子系统）名称一起给出，如图4－10所示。
图4－10 用例的表示法
特别需要注意的是，用例名称表达了一个系统功能，应该以动宾短语形式出现，即这个事件必须有一个动作和动作的受体。图4－11中右图表示了正确的用例名称描述方法，像左图那样用一个名词来表示用例名称是绝对错误的。
图4－11 用例名称的正确描述方法
从用例的定义可以看出，用例是对系统用户的功能需求的描述，表达了系统的功能和提供的服务。用例除完成系统内部的计算与工作外，还包括与一些行为者的通信，即通信关联。每个通信关联都代表了一段对话，行为者与用例之间进行对话的渠道用一个带箭头或不带箭头的线表示，如图4－12所示（注意此图仅为示意，不表示具体的用例图）。
图4－12 通信关联示意图
箭头表示谁发起了这次对话，没有箭头则表示任何一方都可能发起对话。和DFD中的定义不同，箭头并不表示数据流，在这里数据流总是双向的。
1）用例的特征
（1）响应性：一个用例不会自己自动执行，总是被行为者启动。行为者的愿望是用例存在的原因。不存在没有行为者的用例，也不应该由用例主动启动另一个用例。
（2）回执性：用例执行完毕，向行为者提供可识别的返回值。用例的执行结果对行为者来说是可观测的和有意义的。
（3）完整性：用例表示一个完整的功能，必须是一个完整的描述。
2）寻找和确定用例
（1）用例分类(www.xing528.com)
系统分析人员必须分析系统的行为者和用例，它们分别描述了“谁来做”和“做什么”这两个问题。一般习惯上根据用例产生的阶段和功能不同把用例分为业务用例和系统用例。
①业务用例：系统开发开始阶段，在确定用户需求的过程中，系统分析人员通过与客户交流建立业务模型来发现和确定的用例。
②系统用例：系统构造阶段，系统分析和设计人员在进行系统分析和设计时，根据系统的需求建立的用例。
（2）确定业务用例
业务用例是系统提供的业务功能与行为者（用户）的交互，描述问题域中各实体之间的联系和业务往来。在建立业务需求模型时，可以通过与每个行为者（用户）交流以下与业务有关的问题来寻找和确定用例：
①用户（执行者）需要系统提供哪些业务功能，即系统能做什么？
②用户最关心系统中哪些事件？从功能观点看，这些事件表示什么？
③用户要了解系统在工作中发生了哪些事件及相应结果。
④用户自己需要做什么？
⑤用户是否要在系统中创建、删除、读、修改或存储某类业务数据？
⑥系统的新功能是否能使用户的日常工作简化或提高效率？
通过与用户的反复交流，确定主要业务用例和次要业务用例。建立的每一个业务用例都需要一组系统用例来辅助和支持。
（3）确定系统用例
系统用例是行为者与系统的交互，它描述了系统的功能需求和动态行为。系统用例用于建立系统用例模型，可通过分析系统的业务流和控制流来寻找和确定系统用例：
①系统为了维持正常运转需要增加的功能和信息的交互。
②这些信息从何而来，到哪里去？
③实现当前系统（可能是人工系统而不是自动化系统）的关键问题是什么？
在系统开发的开始阶段，应把注意力集中在业务用例上，在精化阶段和构建阶段再考虑系统用例。开发一个项目所选取用例的个数应该适当，以简洁、准确、完整地描述系统功能需求和方便系统开发运作为标准。
识别用例最好的方法就是从分析系统的行为者开始，考虑每个行为者是如何使用系统的。以上分析得到的用例可能没有明显直接的行为者，但在使用这种策略的过程中可能会发现新的行为者，这对完善整个系统的建模有很大的帮助。用例建模的过程就是一个迭代和逐步精炼的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精炼成完整的规格说明。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
