用例和UP的讨论

在我看来UP以及RUP提供了一个对于软件过程关注点的提纲。知道有这些东西就是了。这样看来，它是个不错的参考。



用例方面我认为比较好，比较专业，值得推荐的书是《用例建模》-- Use Case Modeling。《编写有效用例》的论述确实与Ivar的观点有些不同，比如Level的使用，不区分业务用例，系统用例等。
不过我现在已不认为用例是捕获需求的最佳方法了。


XP其实不存在不够工程化的问题。黑人认为白人太白，白人认为黑人太黑。
我认为过程没啥理想不理想的，只有适合与不适合，关键是是否适合项目开发的涉众。

UP 细致的分工在国内很多小型软件公司完全不现实，国内软件公司很多项目只有4、5个人做，根本无法满足这样的分工（根本找不到满足分工需要的专业人才）。如果实施 XP 至少需要 6 人的话，实施 UP 需要的人更多。要骂只能去骂老板，为什么这么抠门，压成本压到这样低的程度。国内这样极端恶劣的开发环境必须要去依赖英雄式的开发人员（而不是“工程”）。这是以前 o6z 认为 XP 也不够极限的原因。XP 和 UP 都不是国内的软件公司能够照搬的东西。庄表伟认为归根到底不是过程的问题，而是人的问题，我也这样看。《人件》里面强调了软件开发中对人的重视，以及形成团队胶合的重要性。“安得猛士兮守四方”，千里马少有，伯乐更是极为罕见，这是目前国内软件行业的现状。

是的，Jacobson 推荐的最佳用例著作也是这本书。用例不是捕获需求的最佳方法，这也是我们以前达成的共识。包括 o6z、robbin 和我都是这么想。

这句话可以说领会了软件工程的精髓。软件工程是用来实践的，不是被精英分子天天挂在口上把玩的，也不是用来考古或者训诂的。哪怕它看起来不够完美（例如 XP），只要我们觉得适用就是最好。对于软件工程理解最深入的不是脱离了编码的精英分子，而是战斗在第一线的开发人员。如果他们从直观出发认为某种方法不会有效果，那么这种方法基本上就可以判处死刑了。

我再补充一下，用例（无论是文本形式还是 UML 图形形式）最大的优点是它的结构化和精确性。这是其它获取需求的方法无法取代的。所以如果需求需要达到比较高的精确性，用例还是必须要采用的工具。
另外大多数情况下，文本形式的用例比 UML 图形形式的用例更加有用。

用例是一组活动的定义，实际上就是流程描述，而用例图是把一些用例抽象成一个图形而已，更加强调用例之间的关系。并不存在所谓的文本形式的用例和图形形式的用例，这种说法很容易让人产生误解的。

这种区别是存在的。你可以看一下大公司的用例，其实 IBM、HP 这样的公司做项目，用例一般都是文本形式的。
用例是 Jacobson 博士创造的一个概念，并且被广泛采用，用例驱动成为了现代开发过程的一个标准特征。不过在 UML 诞生之前，用例的主要形式还是文本的。所以不要把用例和 UML 中的用例图混为一谈。

用例的死穴有以下几点：
1.用例交互本身就是一种设计，限制了多种设计的可能；
2.引入“扩展”、“包含”、“泛化”规范化的关系，添加了不必要的复杂；
3.过多涉及细节，必然导致维护成本升高。

典型的后果就是除了程序员和测试员外，用户根本不会来看用例。

呵呵，佩服啊，怎么我留着准备以后再说的话都让你给说完了。
用例确实存在这些问题。在《面向使用的软件设计》中，另外一位软件工程大师级的人物 Larry L. Constantine 明确指出了用例的这些问题，这些问题限制了更好的交互设计。Constantine 在这本书中提出了一个更加抽象的“基本用例”的概念，基本用例只描述用户的意图，而不涉及任何具体的实现方式，因此可以产生更加紧凑的模型。
以前我在 JavaEye 介绍过“基本用例”的概念，不过没有多少人关注。
详细情况见《面向使用的软件设计》第 5 章。

这是原始的用例的定义，但是一个概念是可以随着使用的深入而有新的理解
例如
1。使用dlee所说“基本用例”的概念，
2。还有在需要时抛弃“扩展”、“包含”、“泛化”的关系,力图使用例让客户能直接看懂
3。隐藏细节，使用隐喻。

赫赫，
1。基本用例也包含了交互，就不可避免的会限制交互设计,而且使用基本用例会使得需求变得晦涩，不容易理解。
2。如果你抛弃这些关系，那么就会重复，这是不可避免的。
3。你是在说XP而不是用例吧。 用例就是要表达这种细节，否则开发设计就会缺少信息，比如"返回客户信息"，就需要把客户信息包含的具体内容描述出来，否则后面定义接口，就会不知所措。套用一句话“你要写出来啊，你不写出来我怎么能明白呢？”

可能我上面说得不够清楚，“基本用例”完全不包含交互，只用来描述用户的意图，比如是“我想要取钱”，而不是“我想要从 ATM 取款机通过敲键盘输入密码的方式取钱”。“基本用例”是和用例不同的概念，Jacobson 大师的用例在《面向使用的软件设计》中被称作“传统用例”。提出“基本用例”这个概念正是为了解决你上面提到的用例太倾向于实现的问题。