用例最初由瑞典电气工程师Ivar Jacobson设计，他也是统一建模语言（UML）开发的重要推动者。用例是从用户视角表示功能需求的一种方法。它被称为目标驱动，因为用例定义了用户在与系统交互时试图实现的目标。Enterprise Architect 完全支持用例图的开发，同时也全面支持用例文本的建模和管理;它拥有一种独特且高效的用例工具，称为场景构建器。
EA不仅能对用例进行任何详细程度的建模，还能自动生成行为模型，使用例的详细步骤及用户与系统之间的交互能够可视化并与模型的其他部分关联起来。
用例与用户故事非常近，后者被应用于多种敏捷软件开发技术中。最初在瑞典语中创造的术语更自然地译为“使用场景”，这对该方法提供了更有说服力的解释。
9.1 需求和用例
用例技术本质上非常简单，最初设计目的是确保功能需求从用户的视角来编写。这一观点有助于确保部署的系统符合需求，并被多元用户社区接受。然而，存在大量相互矛盾的文献以及定义用例的各种样式。这导致了混乱和不确定性，也削弱了这种有效且简单技术所能获得的价值。
在软件工程中，许多方法规定使用用例作为需求开发的替代方案，因为统一建模语言（UML）不包含正式的需求元素。相比之下，大多数基于模型的系统工程方法使用SysML结合了用例和需求。这是因为 SysML 定义了用例元素和需求元素，使这两个元素能够相互关联，并补充系统规范，从而为需求工程和管理这一重要学科带来清晰和精准。
在这两张图中，建模者使用了 <<refine>>关系来表示Decelerate Car用例细化或添加额外的解释来阐明需求Master Cylinder Efficacy 。这提供了一种机制，可以追溯与用例相关联的实现级组件，追溯到需求，最终到达利益相关者。
可追溯性窗口还可以用于查看不同抽象层次下的模型元素之间的连接，以及从子系统组件组成部分的模块与指定该功能的需求之间的连接。
用例通常用于细化高层需求，并表达用户与系统之间的通信与交互。
9.2 介绍用例图
用例图是一个简单的图，直观地描述用户对系统或系统部分的目标。这可以被意译为“系统为参与者提供的价值”。用例图看起来相当简单，包含少量元素：
这些是由一系列关系连接起来的。
主题（边界）为定义提供了上下文，代表系统或系统的一部分;参与者从定义上讲，位于主体之外，而用例则置于主体之外。通信路径关系定义上跨越主体边界，因为它连接了一个参与者与用例。同样，关系数量有限，但每个关系在图中都有特定含义。
与所有 SysML 元素一样，元素兼具图形性和文本性，在用例描述中通常更强调文本或叙事性。
可以创建任意数量的用例图来表示用户与系统或系统部分的交互。需要理解的是，用例旨在描述系统为用户提供的价值，而不应通过功能分解来细分。这无疑是新手建模者最常犯的错误，导致该技术带来的深远益处被削弱。
用例模型可以通过一种称为“构建用例模型”的机制进行美化，该机制将重复的文本分解出来，对角色和使用案例进行分类，并指定扩展点。
创建用例图
用户界面中的多个位置可以创建用例图，通过选择以下方式：
我们用设计功能区来创建一个用例图。首先，在浏览器窗口中选择你希望创建用例图所在的位置。与所有图一样，这可以是包或元素，但通常会在包中插入用例图。在浏览器窗口中选定包位置后，选择：
设计>图>添加图
选择此选项后，模型构建对话框中的“图示构建器”标签页将打开，选择图类型并命名图;名称最初默认为包含该图的包或元素的名称。选择SysML视角并选择SysML版本后，会显示一系列图类型，方便你选择用例图。点击“创建图”按钮，在浏览器窗口中选择的位置创建新的用例图。图示视图将被打开，允许你开始添加描述系统将为用户提供的价值的元素和连接器。Enterprise Architect 还会显示图工具箱中的“用例”页面，其中包含 SysML 规范中定义的元素和关系，以适用于构建用例图。如有需要，除了始终可用的“通用元素”和“通用关系工具箱”页面外，还可以打开任意数量的其他工具箱页面。
用例图中使用的最重要元素和连接器包括：
元素
连接器
元素可以通过从工具箱拖拽到图示视图中添加。最好从边界元素开始，边界元素的命名应恰当，以描述用例图所建模的系统、子系统或实体。将名称留空，或给出一个无法向读者明确说明所建模的系统或系统部分的名称，可能会导致对图的误解。添加边界并在图中适当调整大小后，可以添加参与者和用例 - 参与者位于边界之外，使用例位于边界之内。下一步是在参与者和使用使用例之间添加通讯路径关系，从而定义参与者从系统中获取的值。。
一旦基本图创建完成，并且随着对领域和系统行为的了解进一步加深，就可以利用包含（Include）、扩展（Extend）和泛化（Generalize）等附加关系来创建或者修饰图。新手被提醒不要过于随意地使用这些关系，任何试图使用功能分解的尝试都会削弱用例模型的价值。该模型在描述中故意宽泛，以便利益相关者能够全面地了解被建模的系统、子系统或实体所提供的服务。
9.3 认识场景构建器
使用场景工具种类繁多，但没有哪个比场景构建器更重要和实用。这一独特工具弥合了传统文字处理器或将用例图及其演员和用例分离的孤立工具与场景步骤之间的鸿沟。
场景构建器还提供一种机制，可以直接从场景步骤自动生成行为模型，使架构和设计的元素能够与各个步骤关联起来。
该工具提供了一系列适合任何用例或需求流程的选项，从通常所说的简单流程（即命名参与者和用例，并对用例进行描述）到部分完成的流程（即基本流程已实现）。一个完整的流程通常会详细说明基本流程中的所有步骤，并定义和详细说明备用和异常场景的步骤。
此外，还可以添加任意数量的约束，如前置条件、后条件以及不变量。
9.4 构建用例模型
虽然用例模型提供了高水平的可视化，并且系统工程师被警告不要应用功能分解，但 SysML 确实提供了许多有助于构建用例模型的机制，以确保可以重复使用离散的功能片段。这些机制由<<include>>Dependency、<<extend>>Dependency 和相关关系组成。
9.5 生成行为图
Enterprise Architect有一个有用的生产力工具，它可以根据场景构建器中定义的用例规范自动生成行为图。这提供了一种可视化这些文本描述的方式。它还允许在用例描述中的步骤和其他建模元素之间绘制关系。
9.6 用例文档
用例文档的创建传统上是一个手工过程，许多项目中的文档长达数百页，其制作过程消耗了宝贵的项目资源。这些手工制作的文档变得难以维护，且与项目的其他部分（如需求、业务规则和解决方案组件）隔离。Enterprise Architect 有一个多功能工具叫做 Scenario Builder，允许建模者在模型内指定用例和场景，这些可以通过内置模板自动生成高质量文档。内置有两个模板可用于生成用例报告：一个在摘要层面记录用例，另一个在详细层面记录。
用例报告示例内容
详细的用例报告将列出用例的所有细节及详细步骤，包括基本路径、备用和异常场景。报告还将包含其他信息，包括内部需求、前置和后置条件及其他约束条件。如果自动创建了行为图，如活动图，该图也会显示在报告中。
