需求-扩展用例
有时，可能在两个用例之间需要另外一种连接，这种连接很像扩展机制。
考虑这样一个例子。
你正在设计一个新文字处理程序，叫做Wapp。主要的用户活动是键盘输入。然而，用户可能突然决定改变缩放尺寸或字体，运行拼写检查程序，或者进行许多与键盘输入无关的操作。实际上，你希望键盘输入活动与发生在文档中的任何其他动作都无关。
更重要的是，你希望不同的软件开发小组在对这些服务提出新建议的同时，不会因为新建议而导致基用例的修改。你希望能够在没有大变动的情况下扩展需求文档。
下面描述了上述情况的特征。
有一个主活动，主活动可以被中断。
主活动可以被多种方式中断，并且不能控制中断。
这和系统有一个主菜单的情况是有区别的，主菜单列出了用户可以选择的系统服务。主菜单控制着用户的选择，然而在我们的例子中，主活动不进行控制，而且可以被其他的活动中断。
在这个实例中，不希望基用例显式地表示出所有的中断用例。如果每个人或小组在加入一个新的中断用例的时候都修改基用例，这样将会产生非常头疼的维护问题。每次的修改可能使用例变得混乱，或者每次修改都需要更新版本、重新评审等。
可以考虑使用与描述场景扩展相同的机制，但在这里是创建新用例。新用例称为扩展用例(extensionuse case)，它除了是独立的用例之外，其他都与场景扩展相同。就像场景扩展一样，扩展用例从一个条件开始，在基用例中该条件可能满足的地方被引用。应将所有的条件都放到模板的触发事件(Trigger)部分中。
为了解释清楚，我们从文字处理程序Wapp.的用例中摘录出一部分。图10-1显示了在UML图中 Wapp的情况。我特别使用了一个特殊形式的连接符(一个钩子)来指明用例扩展(或者钩到)另外一个用例。