扩展用例最常出现的场合是当有许多用户想启动中断基用例的异步服务时。通常它们由不同的小组开发。这种情况出现在收缩包装的软件包的构造过程中如图所示。其他通用的场合是对一个锁定的需求文档编写补充材料。在一个增量式开发的项目中可能在每次交付后锁定需求然后通过扩展在锁定的用例中增加功能。扩展点最初发明扩展的原因是由于在开发过程中无法再改变以前系统的需求文档这个实际情况。在使用用例开发早期的电话系统中经常在业务中增加异步服务于是使用了扩展关系。在安全锁定需求文档的情况下新开发组可以在基用例的适当位置增加新的异步服务需求而不能改变原始系统需求中的任何行。然而在其他用例中的引用行为有些问题。如果没有使用行号怎么能找到扩展行为发生的地点呢?如果使用行号在用例被重新编辑过且行号改变时将会发生什么情况呢?回忆一下行号实际上就是行的标号。既然这样它们不必是数字的或顺序的。它们的存在是为了增加可读性以便扩展条件有一个引用点。然而行号通常是顺序的编字这意味着它们会随着时间而改变。引入扩展点是为了解决这些问题。扩展点在基用例中是一个可见的公共标号通过别名确定用例在某个时刻的行为(技术上它可指一系列位置但这段时间我们先不考虑这个问题)。引入可见的公共扩展点带来了新问题。基用例的编写者需要知道在哪里进行扩展只要有人想在一个新地方进行扩展时编写者就必须回去修改基用例。但是回顾一下:扩展的本意就是为了避免修改基用例。你必须处理以上问题。我发现定义公共扩展点带来的麻烦比它们的价值更大。我宁愿用文本描述扩展用例在基本用例的什么地方开始而不用别名正如下面的ATM例子所示。如果你确实使用了扩展点那么不要在图中将它们表示出来。它们会占用椭圆的大部分空间控制读者的视线模糊了许多重要目标的名称。它们所表示的行为也不要在图中显示出来这会引起更多的混乱。关于扩展点还有一些事情。如果需要在基用例中通过扩展用例增加行为扩展点的名字允许按你所需的数目在多处被调用。例如当增加扩展用例一使用其他银行的ATM时对ATM用例可能需要这样。扩展用例需要说明:在完成事务之前系统得到来自用户交纳附加服务费的许可。当完成所要求的事务后系统从用户的账户中扣除附加服务费。当然也就能说这些。