评张逸“双环驱动”文章中的用例规约（01-05）
评张逸“双环驱动”文章中的用例规约（06）
原文[07]
点击“新建订单”
（1）用词不一致
用例名是“创建生产订单”，这里写“新建订单”，是有所考虑还是习惯性换词？
（2）把假想的“界面设计”当成需求
功能需求是“系统应允许计划员向其请求新建生产订单”，以用例规约的形式表达，这一句应该写成：
计划员请求新建生产订单
到底是通过点击某个控件还是别的交互方式来做到，不是功能需求，不能写在用例的步骤里。
但有人会忍不住想加点什么或者多发挥一下。
例如，有的人选择写【点击“新建订单”】，而且有理由：界面很重要！有的时候功能差不多的系统在市场上分高低，靠的就是界面看得舒服一点，用得舒服一点。我这也是为用户考虑啊！
（前文说过，“用户”一词不严谨，应该写“涉众”。此处为了贴合所描述的场景，依然使用“用户”。）
甚至他还有更进一步的理由：我问过用户了，他说【点击“新建订单”】可以！
甚至还有比更进一步还要更进一步的理由：这可不是我瞎编的，是用户告诉我的！他的原话就是，我想点这么一下，然后这么一下，然后又这么一下……
有的人受过一些需求技能的训练，知道写【点击“新建订单”】不妥，但不加点什么东西又觉得不踏实，思来想去，加个“可用性需求”吧：界面要以用户为中心，方便易用，高端大气上档次，低调奢华有内涵……。
有的人懂得更多，他讥笑：什么以用户为中心，方便易用，这是废话！“可用性需求”应该写“手指的操作次数不得超过**”——这个肯定没问题，就算要求严格的潘老师，也是这么写。
可是，还是不行啊！
我们来把背后的道理一点点讲清楚。
**********
首先要说明一下：
根据前文的评点，这个用例规约可以不需要【计划员点击“新建订单”】或【计划员请求新建生产订单】这样一个步骤，但为了评点[07]，我们暂时忽略这一点，强制认为有【计划员请求新建生产订单】这么一个步骤。
好，我们开始。
【计划员请求新建生产订单】这个步骤（功能需求），是建模人员在业务建模和需求工作流推导出来的，例如，从现状业务流程推导出目标系统有一个用例【计划员→创建生产订单】，然后再从这个用例推导需要哪些步骤，得到其中一个步骤【计划员请求新建生产订单】。
假设【计划员请求新建生产订单】这个步骤不再加其他补充约束，就这么一句功能需求，我们来看接下来怎么做。
接下来是分析工作流，我们会添加或更新【计划员界面】边界类。注意，这里说的是“添加或更新”。
如果在【计划员→创建生产订单】用例之前，已经有以计划员为Actor的其他用例进入过分析工作流，那么之前已经存在【计划员界面】这个分析边界类。
此时，分析【计划员→创建生产订单】的用例规约得到的边界类责任，被更新到已有的【计划员界面】边界类上，也许是新增责任，也许是复用已有的责任——是的，有可能之前分析别的用例时已经理出了完全一样的责任。
到此，即使还没有进入设计工作流的交互设计环节，只考虑分析的边界类，也已经看出问题了。
张逸老师设想了这样的图形界面实现：
点击“新建订单”。输入订单基本信息(订单编号、产品编码、数量、交期)……
其实也可以考虑在拥有某一个输入信息且拥有较多参考信息的已有窗体上操作，例如，在展示销售订单的窗体上请求生成生产订单（用例规约的简要描述有写：根据销售订单或预测需求在MES中创建生产订单）。
★张逸老师所给的用例规约中，“基本流程”以下的内容似乎和“简要描述”所说的“根据销售订单或预测需求在MES中创建生产订单”不一致，这个问题另外评点。
分析工作流的边界类只提炼输入、输出的责任以及需要流动的核心域Item，不假设任何的实现。
接下来是D-设计工作流，开始考虑具体的实现。
在设计工作流，和人类Actor交互的边界类（例如【计划员界面】），会比其他边界类多一个交互设计的环节。
===待续===