用例模型描述的是新系统规划的功能。它表示用户（人或机器）和系统之间交互的离散单元。该交互是一个有意义的独立单元，如：创建账户，浏览帐户信息。
每一个用例描述建立在规划系统中的功能，它可以包含另一个用例功能或用自己的行为扩展另一个用例。
一个用例描述通常包括：
- 描述用例的常规注释和说明
- 需求 - 用例必须提供给最终用户正式的需求。如：<ability to update order>"能更新订单"。它们都对应构造方法中建立的功能规范，并建立用例执行动作和给系统提供值的约定。
- 约束 - 用例运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做。包括：
- 预置条件是用例运行以前就已经发生了。如："创建订单" <create order>必须发生在"修改订单"<modify order>之前。
- 后置条件是用例完成后必须为真，如："订单修改和一致性检查"。
- 常量在用例的整个运行过程中始终为真，如：一个订单一直有客户号。
- 情形 – 用例执行时各步骤正式有序的描述，或用例实例化过程中事件发生的流程。它包含多种情形来应付特殊环境和可选择的处理方式。它们通常由文本建立和对应于顺序图的文本表达。
- 情形图 - 描绘工作流的顺序图;类似于情形，但是图形化描述。
- 附加属性，如实施阶段，版本号，复杂性程度，构造型和状态。
执行者
用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工作从而帮助他们完成目标。执行者参与的用例定义了它们在系统中总体的作用和动作的范围。
包含和扩展用例间的关系
一个用例可以包含另一个用例功能做为它自身正常运行的一部分。通常假设在用例运行时被包括的用例每次都会被调用。例如：在修改选定订单前，列出一份客户订 单表，每次<modify order>"修改订单"用例执行时，<list orders>"列出订单"用例被调用执行。
一个用例可以被一个或多个其它用例包含。通过将通用的行为提炼成可以多次重复使用的用例，有助于降低功能重复级别。
通常，在特别情况下，一个用例可以扩展另一个用例的行为。例如：如果一个用户在修改一个特别类型的客户订单之前， 该用户必须得到某种更高级别的许可，然后“获得许可”<Get Approval>用例将有选择地扩展常规的“修改订单”<Modify Order>用例。
顺序图
顺序图提供随时间变化，对象交互的图形化描述。通常用来表现一个用户或执行者，对象和组件，以及它们在用例执行过程中之间的交互。一个顺序图典型地表示一个单独的用例情形或事件流。
顺序图可出色的显示文档使用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段验证对象。它显示一个对象到另一个对象的消息流，这些消息流对应着一个类和对象支持的方法和事件。
下面顺序图例示了左侧的用户或执行者初始化事件和消息流，它们对应于用例情形。在最终模型中，对象间传递的消息变成类的操作。
执行图
用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能。这为系统设计者，客户和团队，这些 实际建立系统的人，提供了高级别可跟踪能力。组件和类连接的用例列表说明了必须被组件执行的最少功能。
上图说明用例"Login"实现需求"1.01 Log On to the website"。也显示组件"Business Logic"和"ASP Pages"组件实现部分或全部"Login"功能。进一步细化可显示"Login"界面(一个网页)来实现"Login"用例。这些执行和实现连接定义 了从正式需求，到用例，直至组件和界面的可跟踪能力。
