1、子用例：一个执行步骤可以是一个简单的步骤或者是另外一个用例的名称。
一般的，步骤如果用下划线或楷体字区别开写的话，这个步骤就是子用例，UML用例图的表示就是用<<include>>来表示
2、扩展用例
两个用例之间需要另外一种连接，这种连接很像扩展机制。其具有以下特征：
（1） 有一个主活动，主活动可以被中断
（2） 主活动可以被多种方式中断，并且不能控制中断
可以考虑使用与描述场景扩展相同的机制，但这里是创建新用例。新用例称为扩展用例（extension use case）它除了是独立的用例之外，其他都与场景扩展相同。扩展用例从一个条件开始，在基用例中该条件可能满足的地方被引用。应将所有的条件都放到模板的触发事件部分中。请看以下例子
用例：编辑文档
|
主执行者：用户 范围：Wapp 级别：用户目标 触发事件：用户打开应用程序 前置条件：无 主成功场景： 1． 用户打开文档并编辑 2． 用户输入或修改文本 …… ……用户保存文档并退出应用程序 |
用例：检查拼写
|
主执行者：用户 范围：Wapp 级别：子功能！ 前置条件：一个文档被打开 触发事件：当文档被打开并且用户选择了打开拼写检查程序的情况下，在编辑文档中的任何时候。 主成功场景： ……等等…… |
注意“检查拼写”用例的斜体部分，在基用例（编辑文档用例）中并没有提及检查拼写用例，但在检查拼写用例中通过编写触发事件来引出基用例，基用例没有依赖扩展用例，对于以后的扩展具有很好的灵活性，但相反，扩展用例依赖基用例，基用例改变的话有可能影响扩展用例。
3、在必须的情况下才创建扩展用例，第一种情况是当有很多的用户可能使用的异步服务或中断服务的时候，并且这些服务不应该影响基用例。另一种情况是为一个已经锁定的需求文档编写附加文档的时候。在基用例没有锁定的情况下，扩展是脆弱。
这一章其实是说明了UML用例关系中的include和extend关系。
