软件方法笔记6-系统用例规约

1.用例图只是表达了用例的目标，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例方式组织的需求规约
2,用例通过前置条件（precondition）、后置条件（postcondition）以契约的形式表达需求。用例相当于系统的一个承诺：在满足前置条件时开始，按照里面的路径步骤走，系统就能到达后置条件。


前置条件：用例开始前，系统需要满足的约束。


后置条件：用例结束后，系统需要满足的约束。


后置条件又分为两种，最小后置和成功后置。最小后置指即使在用例失败的情况下系统也需要满足的约束；成功后置指用例成功时系统需要满足的约束。


前置条件、后置条件必须是系统能检测的。
3.入保单”用例的前置条件是错误的。业务代表是否已经把保单交给内勤，系统无法检测，不能作为前置条件；同样，“收银”用例的后置条件也是不对的。顾客是否已经带着货物离开商店，系统也无法检测，不能作为后置条件。


前置条件必须是用例开始前系统能检测到的。储户开始取款的交互前，系统不知道储户是谁，要取多少钱，所以“储户账户里有足够的金额”这个条件是无法检测的。
前置后置条件是约束，不是动作。


例如，“系统记录鉴定结果”是一个动作，不是条件。条件应该是“系统已记录鉴定结果”。


前置后置条件要有系统的味道。


“系统正常运行”、“网络连接正常”等放之四海皆准的约束，和所研究系统没有特定关系，不能作为前置后置条件，否则又将是一大堆正确而无用的废话。
4.会员登录以后可以下单，也可以查看以往订单，还可以退货……，所以图6-4把下单、查看以往订单画成登录的扩展。这是错的。不是先做A然后做B，B就成了A的扩展。扩展的意思是分支。例如，张三先吃饭，然后可能看电视，也可能上厕所，也可能散步。看电视、上厕所、散步不是吃饭的扩展，否则意思就成了“张三可能会以上厕所的方式吃饭”，或者说“上厕所是张三达到吃饭目标的一条路径”。
第二种做法如图6-5，把登录变成被其他用例包含（Include）的被包含用例（Included Use Case）。这样做是正确的。登录用例本来不存在，后来在写用例规约的时候，发现下单、查看以往订单等用例里都有以下步骤集合：


1. 会员提交身份信息


2. 系统验证身份信息


3. 系统保存会员登录信息


4. 系统反馈会员定制界面


为了节省书写用例规约的工作量，考虑把这些形成一个小目标的步骤集合（不是单个步骤）分离出来，作为一个被包含用例单独编写规约。这个用例只被其他用例包含，不由主执行者指向


下单用例规约的步骤集合里，应该有表示包含登录用例的步骤集合：会员【登录】（“登录”二字加了括号表示这是一个被包含用例，它的步骤和约束在另外的地方描述，不喜欢括号可以用加下划线等其他方法以示区分）。有些人觉得这样的话，好些用例里会出现会员【登录】，看起来有些碍眼，就想能不能把它提到前置条件里，那就得到了第三种：把登录作为一个用例，会员已经登录作为其他用例的前置条件，如图6-6。这样用例的步骤看起来更清爽，但是严格来说这也是不对的，登录不是购物网站的用例
这个看起来正确，实际上也是不对的。不同的涉众利益会带来不同的需求。这样做，潜意识里就有着一种追求“需求复用”的思想，会诱导需求人员对不同用例之间的微妙差别视而不见，这对于做需求来说是危险的。


会员登录需要验证码，货管员登录时不需要。系统反馈给会员的是未完成的订单，反馈给货管员的则是最近货品的动态。会员登录可能要求反馈速度很快，而且有百万会员要登录，货管员没有那么严格。这些需求差异不能视而不见


5,虑复用时，已经陷入了设计的思维
6,前置条件是起点，后置条件是终点，中间的路该怎么走？这就要谈到用例规约里最重要也最容易被忽略的部分——涉众利益，即：某类人担心什么，希望什么。只有目标，没有涉众利益，也很难得到正确的需求。


假设我需要1000元现金去买东西，我可以拉开家里的抽屉，如果里面有超过1000元的现金，我就从中拿1000元。如果抽屉里没有钱或者钱不够，我就拿上银行卡，到楼下取款机去取。问题来了：同样的目标，为什么家里的抽屉拉开就可以拿，而楼下的取款机却找我要卡要密码？
背后的原因就是：虽然目标相同，但涉众利益不同。家里的抽屉，只涉及到我和家人的利益，如果我和家人和睦相处，拉开抽屉就可以拿（反之，如果我和家人的利益冲突得非常厉害，那么可能需要买一种长得很像取款机的抽屉才符合我家的需要），对于银行取款机来说，就不是这样了。储户在取款机取款时，涉及的涉众利益如下：


储户—希望操作方便；希望24小时服务；担心权益受损。


银行负责人—希望安全；希望节约运营成本。
7,


正是在这些涉众利益的交锋之下，目前我们日常生活中所看到的取款机的用例片断大概如下：
------------------------------
基本路径


1. 储户提交账户信息


2. 系统验证账户信息合法


3. 系统提示输入密码


4. 储户输入密码


5. 系统验证密码合法、正确


6. 系统提示输入取款金额


7. 储户输入取款金额


8. 系统验证取款金额合法


9. 系统记录取款信息，更新账户信息


……


业务规则


5. 密码为6位数字


8. 取款金额应为100元的倍数；取款金额应少于账户余额；单次取款金额不超过3000元；当日取款金额不超过20000元


设计约束


1. 通过磁条卡或芯片卡提交账户信息
--------------------
8,执行者。执行者如果是人，当然是用例的涉众。执行者如果不是人，自然没有利益主张，不是涉众，但这个非人执行者背后可能会有涉众。例如图6-10，ERP系统不是人，没有利益主张，但背后的ERP系统管理员是涉众。
9,不要写系统不能负责的事情


系统无法检测、不能负责的事情，如果写在用例规约中，会造成误解，让读者以为只要用上了这个系统，这些事情就会发生。这样就模糊了系统的契约，也抹杀了进一步改进的可能。
10,顾客付款和收银员找零是系统无法感知和承诺的，写在规约里，会让人认为用了本系统，顾客就会乖乖付款，收银员会乖乖找零——也许忘记收款和找零正是商场要解决的一个头痛问题。


这种错误，牢记四步曲即可避免，四步曲中所写的都是系统能感知的。
11,扩展路径


扩展路径的定义是：基本路径上系统要处理的意外和分支。


不是所有的意外都是扩展，扩展必须是系统能感知而且要处理的。例如，“储户心脏病发作”是意外，会导致“取款”用例无法完成，但它不是扩展，因为系统无法感知“储户心脏病发作”事件，系统最多能感知“长时间无操作”。
12,业务规则描述步骤中系统运算的一些规则，例如：


如果货物送达日期超过计划中的交付日期，扣减15%的金额


合同的总金额不能超出买方的信用额度


业务规则如果能够用文字说明，就尽量用文字说明
13,6-