用例和UP的讨论

看来你的脑瓜要好好敲一敲了，
柜台不可以有这些吗？（你忘记以前存取款不用输密码，而现在不是有了？未来是不会止于想象的）
我们这里柜台取款超5万的要提前几天通知银行的，难到你们那没有这个规矩？
国庆前一天你有没有到银行取过款，有人取3千都没钱给，分行的钱可是有限的。。。

我说的“基本用例”是《面向使用的软件设计》中提出的一个新的概念，跟你说的 RUP 中的 essential use case 没有任何关系，根本就不是一个概念，仅仅是名字相同而已。你乱翻书也解释不了问题，只能越扯越乱了。就算你的记忆力好也没有用处。
是不是“天下学问，皆出自儒学”？RUP 就是儒学正宗吗？

赫，同学咱是在做需求，不是在空想阿。
深圳这里确实没有啊。
你说的这些规则其实应当放入业务规则中，用例正如你所言，是来描述流程的。

而且你所说的基本用例，越抽象那他就越不容易掌握，因为它会包含越多的变化和不确定性。

恩，看来你该认真读下RUP中Concepts: User-Centered Design章节。
RUP这段论述恰恰是引用Software for Use的，RUP自身并没有明确的引入essential use case。

essential use case 强调的是the semantics—the meaning of the interaction—remain（语义--交互的含义）。但我认为，这对于需求来说，也是多余的。

抛开这些概念的争论，如果你认为需求确实可以不包含交互，那么我想我们就达成了某种程度的共识。

我倒想看看你如何写出不包含交互的用例或者需求的。
说到交互，把上面的例子中提取出你刚刚说的业务规则后，就完全剩下交互了。

自己去看原书吧，不要只看别人转述的孔子思想。
再表达一下我的观点，我一直认为软件工程不是训诂，不是什么阳春白雪的东西。软件工程必须拉下神坛，为普通程序员所理解，才能转化为生产力。因此我们需要使用尽量浅显易懂的语言来解释软件工程（XP 恰好达到了这种目标，很多敏捷开发过程都有这个特点）。可惜的是目前国内绝大多数头上贴着“软件工程推广者”标签的人（跟论坛里的任何人无关，不要对号入座）都没有这样把话说简单的能力。我们再扯下去真的就变成训诂了。简而言之，训诂无法产生生产力。后面的讨论可以由论坛里的训诂爱好者继续，我就不参与了。
Jacobson 大师的一些思想很精妙，但是需要比较长的时间去理解，这样就妨碍了这些思想被迅速接受（甚至也有可能变成了某些精英放在阁楼里面赏玩的东西）。也就是说 Jacobson 大师的这些思想还不能很快转化为生产力。XP 对于我们是现在时，Jacobson 大师演讲中传达的思想（不完全是 RUP，我没有仔细听，但是感觉他不是在推广 RUP。可能是在推广 UP，但是前面不要加上一个“R”）对于我们是将来时。

我没有这样想（也不代表我反对这种想法），我只是觉得传统的用例包含太多具体的交互实现，而对于用户的意图传达的不够清晰，因此需要在前面再加上一个更加抽象的“基本用例”的阶段。以“基本用例”为核心来设计系统，可以使得思维更加发散，得到更加紧凑的模型。其实我们最初的观点基本上是一致的，不知道为何后来产生了分歧。

用例如果不涉及交互或细节，这种用例至少对于测试来说是没什么价值了

咦，咋左右都被你说完了？到好像我理解错了似的。
essential use case的争论大家的观点都已表达的很清楚，没必要再钻牛角尖，就此画上句号。

倒是你说的用户意图，正是我想表达的。
这正是“用户故事”要表达的。通过提纲式的“用户故事”，可以平滑地过渡到“测试先行”的开发模式中。
关于“用户故事”的讨论，已经超出了本贴范围，有时间再另外开帖，深入讨论。

"用户故事"啊，同学。

到现在为止造成的种种迷思，表明了“用例”这个词目前表示的意思还是比较宽泛的，它实际上应该继续细分使用场合，就如同 业务用例 和 系统用例 的分法，我认为系统用例应该比业务用例更着重于交互细节，是业务用例的进一步细化，而业务用例则只需着重表达与实现无关的“谁 干 什么”等的业务需求。
值得注意的是，业务用例比较适合使用来分析，表达我们所谓的“企业应用”的松散的对象模型，对于一个应用程序来说，例如Office，恐怕难度更高，或者需要另外寻找工具了。
2 partech：
show一下你的“用户故事”吧. ;)