设计程序的动态（运行时）行为
首席技术官，NetReliance
2001 年 3 月
在上一篇专栏文章中，我介绍了正式的用例演示的概念。本专栏文章的后几个部分将讨论一些用例。它们是一个复杂的主题并涵盖很多资料，因此我们要花一些时间彻底地考虑这些问题。本月我们关注的是：如何确定该用哪些用例，以及在计划用例时应该考虑的其它事项。
创建用例
让我们再来看看上个月对用例的定义：
用例是由系统的最终用户执行的具有一些有用结果的单一任务。
看着前几个月的 Allen 银行问题陈述清单，几个用例浮现在我的脑海中：
小孩将钱存入帐户
小孩从帐户提取钱
小孩或家长查看存折
家长开户（opening account）
家长更改帐户
家长关闭帐户（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 设计过程系列文章的前五个部分：
Kent Beck 的 XP 方法希望用例小到能在两周内实现。请在 Extreme Planning wiki 阅读相关内容。
Alan Cooper 建议 UI 设计驱动程序设计过程。请在 uidesign.net 的 interview 中了解更多 Alan Cooper 的思想。
工作流程图（连同 UML 的剩下部分一起）在 Martin Fowler 和 Kendall Scott 合著的 UML Distilled, 2nd Ed 一书中有详尽的描述。
设计程序的动态（运行时）行为
首席技术官，NetReliance
2001 年 3 月
在上一篇专栏文章中，我介绍了正式的用例演示的概念。本专栏文章的后几个部分将讨论一些用例。它们是一个复杂的主题并涵盖很多资料，因此我们要花一些时间彻底地考虑这些问题。本月我们关注的是：如何确定该用哪些用例，以及在计划用例时应该考虑的其它事项。
创建用例
让我们再来看看上个月对用例的定义：
用例是由系统的最终用户执行的具有一些有用结果的单一任务。
看着前几个月的 Allen 银行问题陈述清单，几个用例浮现在我的脑海中：
小孩将钱存入帐户
小孩从帐户提取钱
小孩或家长查看存折
家长开户（opening account）
家长更改帐户
家长关闭帐户（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 设计过程系列文章的前五个部分：
Kent Beck 的 XP 方法希望用例小到能在两周内实现。请在 Extreme Planning wiki 阅读相关内容。
Alan Cooper 建议 UI 设计驱动程序设计过程。请在 uidesign.net 的 interview 中了解更多 Alan Cooper 的思想。
工作流程图（连同 UML 的剩下部分一起）在 Martin Fowler 和 Kendall Scott 合著的 UML Distilled, 2nd Ed 一书中有详尽的描述。
设计程序的动态（运行时）行为
首席技术官，NetReliance
2001 年 3 月
在上一篇专栏文章中，我介绍了正式的用例演示的概念。本专栏文章的后几个部分将讨论一些用例。它们是一个复杂的主题并涵盖很多资料，因此我们要花一些时间彻底地考虑这些问题。本月我们关注的是：如何确定该用哪些用例，以及在计划用例时应该考虑的其它事项。
创建用例
让我们再来看看上个月对用例的定义：
用例是由系统的最终用户执行的具有一些有用结果的单一任务。
看着前几个月的 Allen 银行问题陈述清单，几个用例浮现在我的脑海中：
小孩将钱存入帐户
小孩从帐户提取钱
小孩或家长查看存折
家长开户（opening account）
家长更改帐户
家长关闭帐户（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 混乱是不明智的。（当然也有例外，象出现在问题领域的配置问题，如货币表示符号，当然它也可以通过检测当前语言环境来自动完成。）
暂定的用例列表如下所示。
小孩将钱存入帐户
小孩从帐户提取钱
做假设分析游戏
家长开户或更改帐户
家长关闭帐户
在后面的两篇专栏文章中，我将通过深入详细地说明“存款”用例来继续这个练习。我将为您展示用例规范本身和有关正在做什么的详尽注释。
