在UML建模中，用例分析是描述业务实现或系统功能的重要手段。每个用例都代表一个完整的业务流程或功能模块。然而，在实际应用中，某些功能可能并非核心需求，而是作为可选补充存在。针对这种情况，UML提供了扩展用例机制来灵活处理这类场景。
以银行业务为例，"存款"和"取款"是最基础的核心用例。在完成这些交易后，客户可以选择对服务进行评价，但这个环节并非强制要求。我们可以将"服务评价"单独建模为一个扩展用例。值得注意的是，这个扩展用例必须与基础用例相关联，通过带有«extend»标记的虚线箭头连接，如图1所示。
图1 扩展用例的表示方法
在建模过程中，基础用例中可以设置扩展点，这些扩展点标识了扩展功能可能被触发的具体位置。从基础用例的角度看，扩展用例的执行取决于特定条件。当扩展用例名称不能明确表达触发条件时，可以通过添加约束条件来详细说明。例如，"服务评价"的触发条件可能是"客户在完成交易后主动选择评价"，这个条件可以通过注释方式标注在扩展关系上，如图2所示。
图2 扩展关系的条件约束
虽然扩展用例主要用于处理非核心功能，但在实际建模中，它也可以用来描述流程中的不同分支。例如，在支付系统中，"支付"用例最初可能只支持现金支付。随着系统升级，需要增加刷卡和扫码支付功能时，很多建模者会选择使用扩展用例来实现功能扩展，如图4所示。
图4 功能扩展的实现方式
在系统迭代过程中，扩展用例可以形成多级结构。如图5所示，一个扩展用例本身也可以被其他用例扩展。这种层级关系表明，一个基础用例可以拥有多个扩展用例，同时一个扩展用例也可以被多个基础用例共享。
图5 多级扩展结构
扩展关系与包含关系既有相似之处也有明显区别：
共同特征：两者都使用带箭头的虚线表示；调用时都不涉及参数传递；都支持多对多的关系模式。
主要差异：扩展关系的箭头方向与包含关系相反；扩展功能是可选的，而包含功能是必须的；扩展关系通常用于处理非核心需求，包含关系则用于处理必须实现的子功能。
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/9141.html
