2025年UML 用例图_uml建模用例图和细化用例

UML 用例图

参考

【UML】— 用例图
用例图
初学UML——用例图
需求中如何画用例图

为什么使用用例图

从业务事件、发起事件以及系统如何响应这些事件来建模系统功能的过程。

用例建模起源于面向对象建模。

概念

图形化地描述了谁将使用该系统以及用户希望与系统交互的方式。

业务事件的文本描述以及用户如何与系统交互以完成任务。

参与者

参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。

参与者位于系统边界之外，而不是系统的一部分。

可以是：人，组织，另一个信息系统，外部设备，甚至时间。

确定参与者

从以下角度确定参与者

为系统提供输入的人或事物

接收系统输出的人或事物

需要接入的第三方系统或设备

时间是否会触发某些事件

负责支持或维护系统中信息的人

参与者分类

主要业务参与者：主要从用例的执行中获得好处的关联人员。

主要系统参与者：直接同系统交互以触发业务或系统事件的关联人员。

外部服务参与者：响应来自用例的请求的关联人员。

外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。

参与者的泛化关系

当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。

与类相似，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。

用例

用例是类元提供的一个内聚的的功能单元，表明系统与一个或多个参与者之间信息交换的顺序，也表明了系统执行的动作。

简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合，以及结束时应该返回的可观测、有意义的结果，其中也包含可能的各种分支情况。

用例与用例图被广泛使用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。

确定用例

用例的特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否准确的依据。

用例是动宾短语

用例是相对独立的

用例是由参与者启动的

用例要有可观测的执行结果

一个用例是一个单元

用例与参与者

一个用例可以隶属一个或多个参与者，一个参与者也可以参与一个或多个用例。

用例与参与者之间存在关联关系。

主参与者与次参与者：通常来说主参与者是用例的重要服务对象，而次参与者处于一种协作地位。

用例的粒度

在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜。即一个用例可以描述一项完整的业务流程。例如取钱、报装电话、借书等表达完整业务的用例，而不要细节到验证密码、填写申请单、查找数目等业务中的一个步骤。

在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整事件流为宜。可以理解为一个用例描述一项完整业务中的一个步骤。

在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完成交互为宜。例如，填写申请单、审核申请单、派发任务单等。可以理解为一个操作界面或一个页面流。

泛化关系

与参与者的泛化关系相似，用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列，并且可以增加属于自己的附加属性和操作。

父用例同样可以定义为抽象用例。

依赖关系——包含

包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。

包含的两个基本约束：

基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；

基用例一定会要求包含用例执行。

扩展

扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。

在这一关系中，扩展用例包含了一个或多个片段，每个片段都可以插入到基用例中的一个单独的位置上，而基用例对于扩展的存在是毫不知情的。使用扩展用例我们就可以在不改变基用例的同时，根据需要自由地向用例中添加行为。

用例图示例

依赖关系对比

用例描述

一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。

一般的用例描述主要包括以下几部分内容：

用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。

用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。

参与者：描述用例的参与者，包括主要参与者和其他参与者。

用例描述：对用例的一段简单的概括描述。

触发器：触发用例执行的一个事件。

前置条件：用例执行前系统状态的约束条件。

基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。

扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。

结论：描述用例何时结束。

后置条件：用例执行后系统状态的约束条件。

补充约束：用例实现时需要考虑的业务规则、实现约束等信息。