《软件方法》第6章 系统用例规约

那许多简单情节，那许多复杂表情。

《岁月》；词：沈庆，曲：沈庆，唱：沈庆；1995

 

6.1 【步骤】书写系统用例规约

6.1.1 用例规约的内容和工具

用例图表达了用例的目标，但是对于完整的需求来说，这是远远不够的。用例的背后封装了不同级别的相关需求，我们需要通过书写用例规约把这些需求表达出来。用例规约就是以用例方式组织的需求规约。用例规约的各项内容用类图展示如图6-1所示。

图6-1 用例规约的内容

目前UML并未包含用例规约的表示法。过去常见的做法是用Word等文本处理器来书写用例规约，不过扁平文本形式难以高效建立、修改和维护用例各项内容之间的关系。现在已经有专门用于编写用例规约的工具，例如Case Complete、Visual Use Case等，而且越来越多的UML建模工具也开始提供编写用例规约的功能，使得需求人员能够以“立体”的方式来书写和保存用例规约，并以文本、图形、表格等各种视图查看或输出，如图6-2。

图6-2 制作用例规约的工具

图6-1的各项内容中，执行者和用例在用例图已经存在，照搬到用例规约中就可以。剩下的内容，用例图上是没有的，需要另行添加。我们逐个看看其他各项内容的要点。

6.1.2 前置条件和后置条件

用例通过前置条件（precondition）、后置条件（postcondition）以契约的形式表达需求。用例相当于系统的一个承诺：在满足前置条件时开始，按照里面的路径步骤走，系统就能到达后置条件。

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

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

在本书中，后置条件不再像有的方法一样分为最小后置和成功后置。用例怎样才算成功，只写出最像的那个答案。这样就避免掉入“从实现角度看这样可以那样也可以”的陷阱。

前置条件、后置条件必须是系统能检测的。

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

图6-3 系统必须能检测前置、后置条件

前置条件必须是用例开始前系统能检测到的。

如图6-4所示，储户开始取款的交互前，系统不知道储户是谁，要取多少钱，所以“储户账户里有足够的金额”这个条件是无法检测的。

图6-4 前置条件必须是用例开始前系统能检测到的

前置后置条件是约束，不是动作。

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

前置后置条件要用核心域词汇描述。

“系统正常运行”、“网络连接正常”等放之四海而皆准的约束，和所研究系统没有特定关系，不需要在前置后置条件中写出来，否则会得到一大堆正确而无用的废话。

登录可以作为前置条件吗

一些用例规约会有这样的前置条件：××已经登录。下面花一些篇幅来讨论这样做是否合适。

以购物网站为研究对象，登录不是用例。这一点在第5章已经阐述过了。如何处理登录？在过去的不少书和文章里可以看到如图6-5的做法：

图6-5 画法一：把其他用例作为登录的扩展

会员登录以后可以下单，也可以查看以往订单，还可以退货……所以图6-5把下单、查看以往订单画成登录的扩展。这是错的。并不是先做A然后做B，B就成了A的扩展。例如，张三先吃饭，然后可能看电视，也可能上厕所，也可能散步。如果把看电视、上厕所、散步画成吃饭的扩展，意思就成了“张三可能会以上厕所的方式吃饭”或 “上厕所是张三达到吃饭目标的一条路径”。

第二种做法如图6-6，把登录变成被其他用例包含（Include）的被包含用例（Included Use Case）。这样做是正确的。登录用例本来不存在，后来在写用例规约的时候，发现下单、查看以往订单等用例里都有以下步骤集合：

1. 会员提交身份信息

2. 系统验证身份信息

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

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

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

图6-6 画法二：把登录作为被包含用例

按照图6-6的做法，下单用例规约的步骤集合里，应该有表示包含登录用例的步骤集合：会员【登录】（“登录”二字加了粗括号表示这是一个被包含用例，它的步骤和约束在另外的地方描述。不喜欢括号可以用加下划线等其他方法以示区分）。有些人觉得这样做的话，好些用例里会出现会员【登录】，看起来有些碍眼，就想能不能把它提到前置条件里，那就得到了第三种：把登录作为一个用例，会员已经登录作为其他用例的前置条件，如图6-7。这样用例的步骤看起来更清爽，但是严格来说这也是不对的，登录不是购物网站的用例。

图6-7 画法三：其他用例以“已登录”作为前置条件

可能有的人会觉得第三种画法更好，理由是从最终实现上看，会员登录以后可以下单，可以查看以往订单，不用再重新登录，看起来是不是第三种更合理？其实还是第二种更合理。第5章说过，如果在做需求时考虑到复用，可能已经陷入了设计的思维。能够在多个用例中复用登录的状态，这是设计人员的本事，他甚至还可以做到10个用例的界面都从一个模板生成，但不能因此就把10个用例合并成一个。

认为第三种更好的另一个理由也和“复用”有关：当几个执行者在使用某些用例时都会有登录的步骤集合，把登录单独分离出来，可以抽象出一个用户执行者，指向登录，如图6-8。

图6-8 错误：想通过泛化执行者复用用例

这个看起来正确，实际上也是不对的。不同的涉众利益会带来不同的需求。这样做，潜意识里就有着一种追求“需求复用”的思想，会诱导需求人员对不同用例之间的微妙差别视而不见，这对于做需求来说是危险的。

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

更合理的做法如图6-9，分成几个不同的被包含用例。

图6-9 分成不同的被包含用例，较正确

被包含用例（以及扩展用例）严格来说不能算用例，应该有更好的名字，例如“交互片段”，否则名称中带的”用例“二字容易误导开发人员从实现的角度定义用例，而不是从对外提供价值的角度。

http://www.umlchina.com/training/course170902.htm

9月2-3日（周六日）北京软件需求设计UML全程实作公开课