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