需求总是在发生变化

之前的狗门运行的很不错，但是用户很快有了新的想法：它们嫌手动开门太麻烦了，希望能通过识别狗叫声自动开门。

Paste_Image.png

虽然这样的用户很烦人，但是用户永远是对的。

Paste_Image.png

场景中会有多条路径，但是目标只有一个

现在将声音识别器参与到系统中的场景，修改原先的用例。考虑到用声音识别器开门是一种独立的路径，可以这一步分单独分列出来。如下图：

Paste_Image.png

可以将更常用的路径放到主要路径中，声音识别器明显更常用，再次修改

Paste_Image.png

场景

每一条路径都是一个场景。一个用例可以有多条路径，即多个场景，但是所有路径的最终目标都是一样的。

替换路径不能缺少

替换路径虽然不常用，但是必不可少，否则用例就是不完整的，导致需求分析也不完整。

用修改后的用例检查需求列表

用修改后的用例检查需求列表，发现缺少声音识别的功能，因此添加这些功能

Paste_Image.png

为新的功能编写代码

新的需求分析出来以后，可以编写代码。主要增加了一个狗叫识别类

测试新功能，发现问题

测试新功能代码，发现似乎有些问题。通过狗叫开门以后，狗门无法自动关闭。

Paste_Image.png

经过分析发现了问题的原因：之前自动关门的相关代码，放置在了按钮开门之后；而声音识别开门后面没有相关的代码

按钮开门后有自动关门的代码

Paste_Image.png

修正错误，但不要重复

为了修正这个错误，有个程序员认为，可以在声音识别开门后面加上同样的自动关门代码，但是这样就造成了重复代码

Paste_Image.png

将自动关门的相关代码从遥控器类中，移动到狗门类中是更好的方法，不会造成重复

Paste_Image.png

最后再次测试，一切正常了

Paste_Image.png

总结：

• 用户的需求总是在发生变化，因此系统也常常会被修改
• 修改从更新用例开始
• 一个用例从起点到终点可以有多条路径，每条路径都是一个场景
• 替换路径是一条单独路径，虽然不常用但是不能缺少
• 修改代码是应该消除重复