UML 中各种图形的重要性排行

需要分析最重要的一点是从客户哪里挖掘出需求,理解潜在的需求.你不可能去要求客户用你所习惯的手段去表达它.要是客户都能懂得什么叫用例了,那就不叫客户了.
FRS当然不是基于操作的清单(当然,它在很多方面和操作的功能是相似的),它只是业务需求的一种表现形式.FRS与use case最重要的区别是关注的粒度和表现的形式之间的差别.在没有use case的年代或者系统,一样是可以做好软件的,但是前提是必须有一个对业务能够真正做到提纲携领的人,也就是懂得计算机技术的业务庄家, 从而保证在FRS关注细节的同时,也能够保持整体目标的一致性(也就是我前面说过的类似隐喻). 而use case的出现,恰好可以让我们从一个更加抽象的角度去描述和理解需求,同时通过基于use case的SRS来做到需求的细化. 但是use case所面临的问题就是客户是不懂的, 并且use case间的独立性比较强(虽然也有关系),需求分析人员往往不清楚所做的use case是否真正完全地覆盖了需求,而客户也无法给予更多的回答.我个人是倾向于两者的综合.
      期待o6z兄的文章, 也期待更多的交流.

没听说过两条腿走路？

在没有use case的年代，人们根本就不分辨业务需求和非业务需求，认识不予区别这个误区人们，需要适应这种新形势的工具，恰恰use case顺应了这个潮流。
另外，业务专家不需要懂得计算机业务，我认为很多问题恰恰是很多懂得计算机的业务专家引起的。

没有看懂....

没有use case的年代,人们根本就不分辨业务需求和非业务需求???这是谁说的? N多年前就有Business Requirement 和 Use need. 业务专家不需要懂得计算机业务(恕我知识不广,第一次听到计算机业务这个词),这是自然.但这并不代表业务需求分析人员不需要懂得计算机信息系统的知识.很多问题是懂得计算机技术的业务专家引起, 是什么问题啊? 是业务分析不够清晰?还是越权控制开发人员的技术实现啊?或者还是反驳我, 因为这样的人出现从而导致无法保持整体目标的一致性?

或者说业务专家在做业务描述文档时不要越过界限，这个恰恰是很多人没有做到的。

这句话我赞成, 我也很有体会. 不过这主要是"人品问题"了,业务专家们有些喜欢自以为是技术专家,呵呵

Bob大叔（Robert C. Martin）的《UML for Java Programmers》也很不错。

Pete McBreen 在这本书的《序》中说：。。。在此之前，所有UML书似乎都假定读者想成为一名语言律师。

我个人的体验是：类图最常用，用于领域建模。

我的团队通常是这样工作的：
1、在一起讨论需求，我在白板上画domain model，通常只有类名（汉字的）。
2、得出结论后，我在A4纸上手工再画一次。这一次，类名有中英文两种。
3、开发人员每人复印一份，钉到自己的隔断上。
4、domain的开发者会在讨论的时候，重点记录属性和方法，然后先开发domain，再开发持久层。
5、界面开发人员画完界面后，domain已经出来了，就可以编写Action了。

结论：
1、讨论的时候，UML用于沟通。
2、开发的时候，UML用于了解Domain Object的结构和关系（像工厂中的图纸）。
3、验收的时候，UML（反向工程产生）用于糊弄客户。

如果不存在3，不需要买UML工具，连盗版的都不需要。

就是交流工具而已。
客户和需求分析人员的交流用不到：用户很多就不晓得uml。
需求分析人员和设计人员和编码人员之间如果分工极其明确的时候估计可以用到。
但这种分工本身是否合理都有疑问。

我的感受：
1.开发人员（这里没有明确的分工）交流根本用不到uml。
2.uml在什么时候有点用处呢？系统化思路。但这个是事后性质的，做完一件事情然后系统化一下，做个整体把握，在整体认识后有可能有新的想法或见解等。

至于用例是个有趣的东西，也比较实用，但有这种思想就够了，没必要图形化，甚至没必要记录下来，当然也可以写下来供以后忘掉的时候回忆一下。

用例图，活动图，类图，时序图　总结完毕！！！