路径：我们要让它更易读性

小明说“我要去唐兴镇星辰里花香路大头街芙蓉巷9号6栋的表姐小王家。”

我听着听着就睡着了

起来问了下

“啊？什么的小王家？”

我们可以讲，小明的表达方式，真的是长的让人睡着啊。

也许，小明可以这样讲：

“我要去表姐小王家，她家就在唐兴镇星辰里花香路...”。

长句变短句，先表达主旨梗概，再描述细节。

这就是“如何让人更容易懂的表达方式”

而它，也同理，可以用在我们描述用例规约的路径上。

在通过基本路径和扩展路径，表达人与系统的交互的时候，我们只需要表达交互的要点就可以了，不要涉及太多的当前这一次交互的细节。

举个例子，我们在做人口采集的时候，人口的信息项，如身份证，姓名，籍贯，性别等，零零种种，至少是有10项以上，如果是把每个和系统的交互细节都写出来的话，那我们的路径就很长了。

1. 采集员输入身份证信息

2. 系统验证身份证格式正确

3. 采集员输入姓名

4. 系统验证姓名格式正确

。。。

n. 采集员提交采集数据

n+1. 系统验证采集员提交数据正确

n+2. 系统新增人口成功

n+3. 系统反馈“人口采集成功”

用户输入信息，和系统的交互如此繁琐，反而使得弱化了用例规约中最重要要表达的需求的梗概，即采集员采集数据的核心过程，即从第n步骤开始的内容。

这种表达，不会比下面的表达，增加补充验证规则到“业务规则”里面，更让用户清晰易懂。

1. 采集员输入人口数据

2. 采集员提交人口数据

3. 系统验证采集员提交数据正确

4. 系统新增人口成功

5. 系统反馈“人口采集成功”

路径：只保留“不得不做”的交互

除了易读性，我们也考虑从“不得不做”的交互，和“有所选择”的交互出发来考虑这个问题。

用例是有顺序性的。举例人口数据采集，那么如果我们用上面描述的第二种方式的话，到时候到了界面表单设计的时候，交互设计师就可以从用户使用体验的角度，重新考虑这个表单的内容顺序。

但是如果是采用第一种方式，那么就把原本可以灵活处理的表单内容顺序规定死了，也就没有办法在后面让交互设计师放大用户使用体验来重新设计表单的顺序，这一个环节可能就少了一些优化的空间。

那么可以讲，表单项不用一定按照某个顺序的交互，叫做“有所选择”的交互。

而往上面一层剖析，人口数据采集之后一定是要提交给系统处理保存的交互，叫做“不得不做”的交互。

我们在用例规约这里，就只保留“不得不做”的交互。就可以让核心的最重要的交互不偏离。验收系统是否满足软件需求的时候，既严谨，又有灵活性。

两类交互的穿插模型

当然，上面讲的人口采集表单的表单项录入，是有所选项的交互。但是并不是所有的表单都是同样的情况。

例如用户注册的时候，是否先绑定手机之后，让用户处在一个唯一性的情况下，再让他填写其他的信息，避免手机已经绑定了，已经有账号但用户忘记了，使得用户重复填写信息的麻烦。

类似上面的例子，不得不做的交互，依然需要具体问题，具体分析。