OO 设计过程:用例计划

发表于:2007-05-25来源:作者:点击数: 标签:设计用例过程计划
OO 设计过程: 用例 计划 Allen Holub (allen@holub.com) 首席技术官,NetReliance 2001 年 3 月 来自IBM DW站点 在上一篇专栏文章中,我介绍了正式的用例演示的概念。本专栏文章的后几个部分将讨论一些用例。它们是一个复杂的主题并涵盖很多资料,因此我们

OO 设计过程:用例计划

Allen Holub (allen@holub.com)
首席技术官,NetReliance
2001 年 3 月
来自IBM DW站点

在上一篇专栏文章中,我介绍了正式的用例演示的概念。本专栏文章的后几个部分将讨论一些用例。它们是一个复杂的主题并涵盖很多资料,因此我们要花一些时间彻底地考虑这些问题。本月我们关注的是:如何确定该用哪些用例,以及在计划用例时应该考虑的其它事项。
创建用例
让我们再来看看上个月对用例的定义:

用例是由系统的最终用户执行的具有一些有用结果的单一任务。
看着前几个月的 Allen 银行问题陈述清单,几个用例浮现在我的脑海中: 

小孩将钱存入帐户 
小孩从帐户提取钱 
小孩或家长查看存折 
家长开户(opening aclearcase/" target="_blank" >ccount) 
家长更改帐户 
家长关闭帐户(closing account) 
银行贷款给小孩(将在版本 2 中完成) 

在本阶段,此列表只是一种猜想。随着过程的深入,肯定将会发现其它用例。此外,有些用例可能会过大,以至于必须要分解成小块。(通常,在进行到实现级别(implementation-level)设计时,用例的实现不应超过一个月。事实上,对于粗略估计而言,每个用例一个人月是一个不错的经验法则。有些方法 — 如 Kent Beck 的 XP — 需要的是能在两周内实现的较小用例。)请注意我们没有列出低层的原子操作 — 如计算利息,因为它们不是独立的用例。但是这些用例几乎都会成为子例。

现在既然我已经写了一些东西,那么就可以开始设计了。看着前面的列表,我有几个想法。首先,我不能肯定“存款”和“取款”是否为能分割开的用例。替代方法可能是类似于“完成交易”的用例,其中“交易”是存款或取款操作。具有相同工作流的两个用例当然是等价的,但我还不知道我的问题是否属于这种情况。目前,我将把两个用例都保留下来,因为在用户看来,它们显得不同,并且它们的外观结果显然也不同。(存款增加余额而取款则减少余额。“完成交易”用例修改余额。)

当着眼于“查看存折”时,我根本不能确定它是否为一个用例。它没有特别的结果而且存折很可能是在其它用例的过程中被显示。经过考虑,我把这个用例改成“做假设分析(what-if)游戏”,它的确有一个结果:了解财务计划。

接下来,我考虑开户、关闭和更改帐户。同样的,尽管在用户看来结果肯定明显不同,但我可以设想“开户”和“关闭帐户”用例的工作流将是相同的。UI 当然将是相同的 — 只是在开户时某些字段可能会是空白。这些细微差别可以在工作流中用简单的条件分支(“如果帐户是新的,则 ...”)处理。

我决定把“关闭帐户”作为一个真正的(尽管是琐碎的)用例,因为它的 UI 将与开启/更改用例的 UI 不同。我不会象一般的银行那样当余额恰好为 0.00 美元时就自动关闭帐户,因为很容易想象小孩会将他们的帐户余额变为零,而在这种情况下我不想重做设置。

最后,我决定抛开“贷款”用例。它是版本 2 的一个不错的特性,但现在不需要。

请注意在作这些决定时,我正在设想实现的细节(UI)。毕竟我在设计一个计算机程序,所以需要事先考虑它的实现。但是,我还是试着同时尽可能长时间地将思想集中到问题领域。我正在设想着实现以帮助理解域级(domain-level)问题,但我不是在设计实现,我也不是专门做这个的。UI 就是一种帮助我理清关于域级问题的辅助设计工具。这种方法和 Alan Cooper 推荐的 VB 风格的方法有很大不同,后者是 UI 设计驱动程序设计过程。这里,程序将从概念模型中产生,而 UI 仅仅只是开发那个概念模型的便利工具。

象“备份”、“保存”这样的事情不是用例,因为它们不是发生在问题领域。然而这也告诉我们一些有关程序应该如何工作的事情。退出任何程序以前,不一定要显式地“保存”,本用例尤其如此。如果存款,那就是存款。需要一个象保存这样的额外操作才能意识到存款事务是不自然的。我保证十岁左右的小孩在退出前不会考虑什么保存。要是您考虑它,那么我可以告诉您,要求“保存”操作和使“放弃我的所有工作”成为程序缺省行为是同一回事 — 那并不是特别好的缺省行为。“备份”也是一样。要么象更改帐户状态的副作用那样,程序应该自动备份;要么程序必须维护一个审计跟踪以便撤销更改。“任何不出现在域级的操作都应该出现在 UI 中”的情况是很少见的。可能出现的例外也许包括“帮助”,但如果 UI 十分直观就不需要帮助了。您可能会争论说程序应当通过留意您的行为来觉察到您需要帮助,并在那时提供帮助给您。大多数配置选项从来不被用户更改,所以用这种意义不大的东西使 UI 混乱是不明智的。(当然也有例外,象出现在问题领域的配置问题,如货币表示符号,当然它也可以通过检测当前语言环境来自动完成。)

暂定的用例列表如下所示。 

小孩将钱存入帐户 
小孩从帐户提取钱 
做假设分析游戏 
家长开户或更改帐户 
家长关闭帐户 

在后面的两篇专栏文章中,我将通过深入详细地说明“存款”用例来继续这个练习。我将为您展示用例规范本身和有关正在做什么的详尽注释。

参考资料 

请参阅我编写的关于 OO 设计过程系列文章的前五个部分: 
入门 
开始设计软件 
细化问题定义 
验证分析 
用例,简介 
应用的用例,第 1 部分 
Kent Beck 的 XP 方法希望用例小到能在两周内实现。请在 Extreme Planning wiki 阅读相关内容。 
Alan Cooper 建议 UI 设计驱动程序设计过程。请在 uidesign.net 的 interview 中了解更多 Alan Cooper 的思想。 
工作流程图(连同 UML 的剩下部分一起)在 Martin Fowler 和 Kendall Scott 合著的 UML Distilled, 2nd Ed 一书中有详尽的描述。


原文转自:http://www.ltesting.net