第九章 技术和数据的变化
1、扩展说明了系统所完成的目标是不同的，但有时需要表达“有多种不同方法来完成相同目标”。系统所完成的目标是相同的，但怎样做可能不同。这通常是因为技术的变化或输入数据的不同。应该将这些变化写到“技术和数据变化”列表，而不是写到扩展部分中。
示例
主成功场景：
……
2．用户标识自己、银行、账号。
……
技术和数据变化列表：
2a. 用银行卡、眼扫描或指纹来识别。
读书笔记8的第五点中提到寻找扩展可考虑的情况的第一点是：一种可选择的成功路径（职员使用便捷的代码），可能这个所谓的成功路径是有一定步骤的，但目标是和成功场景一致的，应该和本章的技术和数据变化区分
2、技术和数据变化列表不包含条件和步骤。
3、如果决定使用UML用例图，那么你可以为一个基本步骤创建一个空的。一般性的基用例，为每个变化创建一个具体的用例。
这里所说的就是UML用例泛化的关系
总结：本章篇幅只有一页两面，只是说明了一下什么是“技术和数据的变化”
第十章连接用例
1、子用例：一个执行步骤可以是一个简单的步骤或者是另外一个用例的名称。
一般的，步骤如果用下划线或楷体字区别开写的话，这个步骤就是子用例，UML用例图的表示就是用<<include>>来表示
2、扩展用例
两个用例之间需要另外一种连接，这种连接很像扩展机制。其具有以下特征：
（1） 有一个主活动，主活动可以被中断
（2） 主活动可以被多种方式中断，并且不能控制中断
可以考虑使用与描述场景扩展相同的机制，但这里是创建新用例。新用例称为扩展用例（extension use case）它除了是独立的用例之外，其他都与场景扩展相同。扩展用例从一个条件开始，在基用例中该条件可能满足的地方被引用。应将所有的条件都放到模板的触发事件部分中。请看以下例子
用例：编辑文档
主执行者：用户
范围：Wapp
级别：用户目标
触发事件：用户打开应用程序
前置条件：无
主成功场景：
1． 用户打开文档并编辑
2． 用户输入或修改文本
……
……用户保存文档并退出应用程序
用例：检查拼写
主执行者：用户
范围：Wapp
级别：子功能！
前置条件：一个文档被打开
触发事件：当文档被打开并且用户选择了打开拼写检查程序的情况下，在编辑文档中的任何时候。
主成功场景：
注意“检查拼写”用例的斜体部分，在基用例（编辑文档用例）中并没有提及检查拼写用例，但在检查拼写用例中通过编写触发事件来引出基用例，基用例没有依赖扩展用例，对于以后的扩展具有很好的灵活性，但相反，扩展用例依赖基用例，基用例改变的话有可能影响扩展用例。
3、在必须的情况下才创建扩展用例，第一种情况是当有很多的用户可能使用的异步服务或中断服务的时候，并且这些服务不应该影响基用例。另一种情况是为一个已经锁定的需求文档编写附加文档的时候。在基用例没有锁定的情况下，扩展是脆弱。