UML之扩展用例
UML用例建模聚焦于业务达成或系统功能呈现，每个用例对应一项完整业务或功能。一个完备用例可能含非必需附加功能，或在用例实现后需增新功能，此时可借助UML扩展用例机制描述此类场景。
以银行储蓄业务为例，最基础核心用例是“取款”与“存钱”，业务办完后储户常可评价服务，此非必需环节，是两用例可选活动，不评价不影响“取款”“存钱”目标达成。评价服务可单独建模为“评价服务”用例，它依附于“取款”“存钱”用例，通过虚线箭头连接且标“«extend»”，表明是扩展用例，扩展自基本用例，如图1所示。
图1 扩展用例描述方式
图1中基本用例“取款”“存钱”有“扩展点（extension points）”，是构建扩展用例可选项，扩展点是基本用例调用扩展用例位置，似基本用例某点分支。
从基本用例视角，扩展用例可选，那何时选执行？若扩展用例名未明执行条件，建模时需为扩展关系指定约束明条件。如上例，“评价服务”执行条件是“储户服务完成后选评价”，可通过给扩展关系（带«extend»虚线箭头）加注释说明，如图2所示，通常扩展用例触发条件是基本用例状态改变。
图2 为扩展关系添加约束条件
理想中扩展用例扩基本用例非关键活动，实际建模中也描活动流程分支。如某模型“付款”用例，按面向对象思想本应用泛化关系（详见《泛化用例》），如图3所示。
图3 使用泛化建模
实际建模中，初模型因时等因，“付款”场景仅“现金支付”，建模时建“付款”（或“现金支付”）用例实现现金付款流程。后续系统升级要支持刷卡扫码，多建模者选扩展原有用例扩功能，如图4所示。
图4 扩展取代泛化建模
图中“刷卡支付”“扫码支付”仍建模为抽象用例（斜体名），由具体用例实现，正确。若初模型经两次升级，第一次升级时国内无信用卡，仅借记卡和支付宝扫码，升级用扩展用例；第二次升级再扩，完成用例图如图5所示。
图5 多级扩展
图5示用例扩展关系可多级，一扩展用例可自身有扩展用例。一基本用例可有多个扩展用例（如图5“付款”），一扩展用例可被多个基本用例扩展。
用例扩展与包含关系异同：
相同点：都用带箭头虚线；基本用例调用时无参数返回值，似“复制－粘贴”；与基本用例均多对多关系。
相异点：扩展关系虚线由扩展用例指向基本用例，包含关系由基本用例指向被包含用例；扩展用例是基本用例可选部分，包含用例是必选部分。
