OO 设计过程7

OO 设计过程：应用的用例，第 1 部分

详细说明用例

Allen Holub (allen@holub.com)
首席技术官，NetReliance
2001 年 4 月

在本月的文章中，我继续上个月关于用例规划的文章，开始填写第一个

（存款）用例的用例模板。我不只填写了模板，而且提供了有关工作时

思考过程的详尽注释。

有关如何构建用例文档的几条初步注释已准备好。考虑将如何使用模板，我已经排列了模板的各节。不过创建模板的次序很少会与使用模板的次序相同。我已经按模板次序介绍了用例，但当我真正把东西拼装在一起时，我不会固守一种形式。我从名称和描述开始，然后进入并着手进行少许方案工作，接着进入并添加实现的注解，再回过头并进行一定的方案工作。然后，我填写期望的结果部分，添加后置条件，就这样一轮一轮的进行下去。

此外，在现实世界情况中，很少有一个人可以独自开发整个用例。理想的情况是，与商业相关的组件（用例名称、描述、方案、用户目标可能还有期望的结果）将主要由市场营销方开发，而工程方起咨询角色。技术项（依赖性、前置条件和后置条件、正式工作流分析、实现需求和注解）将主要来自工程方，而市场营销组织起咨询角色。商务规则与需求通常共同创建。如果现实的客户 — 产品的实际用户 — 也参与到过程中来就更好了。

您将要并行地设计几个构件。在开发用例时发现问题的迄今未知方面是很自然的，在遗忘之前应该回头把它们添加到问题陈述中。将包含各阶段设计的各种文档保存在一起对于大型设计而言是真正的问题，但它很关键。一旦发现思考问题时的缺陷，就必须立即更改 所有相应的文档。通常在我工作的同时，我会将问题陈述、所有相关用例描述、UML 图和代码都放在我面前。当发现采取的方法不对时，能够回滚到以前的设计是很重要的，可是我不知道有任何自动化文档管理软件包能够做到真正“无痛苦”的回滚，要知道设计是由很多类型的文档 — 图画、格式化文本、ASCII 源代码等等 — 组成，而它们可能都会受到更改的影响。（如果谁知道能胜任此任务的文档管理系统，请给我发电子邮件。）

现在我们来看第一个用例。

样本用例

名称1.0. 小孩将资金存入帐户。描述小孩（客户）将钱存入他／她的帐户。存款生效前必须经过银行主管人／家长的认可。

这在上下文中是第一次出现认可（authorization）这一概念，并且它是编写用例如何能找出问题陈述中的缺陷的一个实例。在我第一次处理这个用例时，我写道“家长和这个用例没有关系”但我后来的想法是“可是怎样防止小孩存入任意数目的钱呢？” 认可的概念解决了这个问题，但也引入了几个有趣的方案，我将在下面讨论。

原始的问题陈述的确涉及到安全性问题，但用的方式并不奏效。这里是原始问题陈述的相应部分：

原始问题陈述
有几个安全性问题。象真正的银行一样，小孩们不能通过自己修改存折进行存款或取款；他们必须要求银行做这件事。银行处理这个交易然后更新存折。也就是说，小孩把钱交给银行，银行再把钱放入帐户。银行从帐户取出钱然后交给小孩。（实际上，这意味着只有家长能够存款或取款，但家长应该按要求处理取款请求，否则小孩会以为银行是一个不让他们拿到自己钱的骗子。）

回顾一下，银行从帐户取出钱并交付那种事行不通，因为银行根本不做那件事（出纳员做，银行主管人做，银行不做）。因此，我现在返回并修改问题陈述，使家长对某种交易的认可的概念与在此用例中发现的更一致。

这里是修正的部分：

修正的问题陈述

有几个安全性问题。只有银行主管人（即家长）能够更改利率，设立新帐户（和初始余额）或者关闭帐户。尽管对于绝大部分交易，小孩都能完全独立地使用银行，有些交易（存款和贷款）需要家长／银行主管人的批准才能完成。对于小孩而言这样的交易是可见的并且在存折上显示出来，但未经批准的存款不能用于取款。取款不需要家长批准。取款要求会导致一张支票被打印出来。这些支票可以象现实世界支票一样使用。如果支票遗失，则发出停止支付的命令（需要收费）。支票可以交给银行（家长）来换取现金。

我是在写作时想到支票的问题 — 设计过程如何运作的另一个示例。当从不同角度考虑问题时，会发现遗漏了问题的某些部分。

当然，在对问题陈述作了更改后，现在需要得到领域专家批准才能检入新的版本。（既然我自己就是领域专家，那就简单了。）

期望的结果帐户余额变得更大用户目标小孩：尽可能地使帐户余额变大并且注视财富累积。

家长：确保小孩没有利用未经授权的任意存款使余额膨胀。

请注意系统的不同用户有不同的目标，而且这些目标经常是相互排斥的。小孩希望帐户余额任意地大，而家长则想确保只有真正的资金 — 小孩们真正可支配的资金 — 被存入。这种目标冲突并不少见，所以当前练习的要点之一就是识别（并解决）这些冲突。

参与者／角色
我将使用上个月讨论的 CRC-card 格式来标识角色。同样，这个列表是我在进行方案工作时逐渐开发出来的；您在这里所见的是该列表的最终形式。

请注意有些参与者是自动化的（出纳员）而其他则是真人。还要注意有些参与者是系统里的被动对象（存折）。这就是用于程序开发的用例与用于 UI 开发的用例可能不同的地方。UI 样式的用例通常只会关心系统的实际用户所扮演的角色。而在 OO 系统里，即使被认为是被动的对象也有定义于其上的职责和操作。（例如，存折可能打印自身内容。）

类职责合作者Kid（银行客户）

• 填写存款单。
• 持有存折。

Teller（处理小孩的请求）Parent（银行主管人）

• 认可存款

Teller（请求存款）Teller

• 收取存款单。
• 从银行主管人处获得许可进行存款。
• 更新存折。

Parent（授权交易），
Kid（提出请求）Account????????Passbook

• 跟踪交易历史

Kid（查看它），
Teller（更新它）Deposit slip

• 标识存款金额

Kid（填写它），

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有