需求-扩展用例

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