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

UML涵盖很广, 作为一种图形语言它并不难, 但是不会有人说可以把它的图形全部画好, 就如同不会有人精通从业务分析到最后实现部署整个过程一样.
    在不同人的眼中,在不同角色的眼中, 每个diagram的重要性是不同的.对于业务分析人员来说, 他们更加看着用例图与活动图, 而对于系统分析人员来说,他们看重状态图和序列图还有组件图.对于设计人员来说,他们看重的是类图与协作图,而对于系统架构师以及部署人员来说,他们更加看着部署图.

你们的功能清单是什么样的，能否举个例子？

楼上各位都是经验累累的开发专家，不需要怀疑他们眼光的全面性，相反，我们恰恰需要的就是偏执。
扩展，包含等应该是在需求获取最后阶段进行优化处理的吧，如果还有交流困难，那就应该到开发初期团队内部范围处理了。
实际上，以前我们就是这样做的，但是现在发现一个严重问题：
当界面原型出来后，负责分析，设计的成员，包括我自己。思路经常被界面原型误导，如果仅以界面原型主导，那么得出的用例非常非常不精确。
还有，用例不应该和具体实现有关，也就是说，如果有一个流程，现在用PC图形界面实现，如果改为使用电话操作，代表这个流程的用例都应该是不需要改动的。以这种方式写的用例，恰恰是留给了设计无限大的空间。

凤舞凰扬说的很对，按道理确实应该是从业务抽象的角度通过use case来逐步细化为功能清单。

之所以说到use case用途没有想像的那么大，也是因为项目的关系，我所碰到的项目，基本上都是在招标前已经定好功能清单，实施过程中基于功能清单进行细化和沟通要比用use case效果要好，客户也不会认可基于use case的计划。

use case我认为它与功能清单的差异在于角色，我们采用功能、角色关系表也比较直观，并且功能清单也会逐步进行细化，直到成为可量化任务的功能点。

对UML的图例我们把它当做和以前开发规范里面的数据流图、流程图一样看待，至少我是不相信CASE工具，也就对UML的哪些复杂的用法不以为然。
UML作为设计说明的图例，规则应该很简单，几句话就应该能说清楚，如果很复杂需要花大量时间来掌握那么厚厚的手册，从我个人的角度上来看，这种东西没有什么价值。

     先回答wolfsquare的疑问吧, 功能需求清单就是FRS(Function Requirement Specification)它是SRS的一种表现形式,另外一种形式就是use case了.在UML发明之前,软件的需求是采用FRS进行记录的. 直到现在,很多老的程序员,包括大部分香港的程序都习惯偏向于FRS.
      回到use case的话题,如果我们只是把use case当作一个图形的描绘,或者说期望将复杂的软件系统完全用图形描述,这其实是不现实也是不恰当的.熟悉RUP的人都知道,SRS的描述是基于用例的,而用例的描述是使用文本的,包括前后置条件,基本备选流等等.而图形化只是让我们能够更加抽象地去了解和看待系统的功能.另外,用例的最大一个好处是用例的独立性与用例的扩展性, CASE工具之所以越来越强大,其实UML的出现, Use case概念的出现是功不可没的. 身为程序员的大家都知道codecoverage, 而在系统软件分析层次同样也有coverage, 那便是用例的覆盖,同时系统用例可以扩展为测试用例与实现用例,从而分别指导了测试与设计两大流程.
     一蓑烟雨任平生, 建议你去使用CaliberRM或者RequisitePro这两个需求管理工具,其实它们已经很好地将FRS与SRS有机地结合了起来.

功能清单定义大家都清楚，但是不同的人写的功能清单可是有很大不一样的。

FRS相对于usecase最大的好处就可以将功能细化并予以编码，从而在实现与测试中关注该功能需求是否实现。也就是说FRS与Use case在后续软件开发过程中所导致的关注点与覆盖度不同。在很多时候，如果检查不严格，那么表面上，某个实现的确覆盖了某个use case，但是并不代表它覆盖了某条功能需求，而use case间的相对独立性，有时又让这种问题比较难以发现。所以我们经常会碰到需求的不断变化，其实当中很大一部分是因为基于use case的SRS中无法统筹一些功能需求。
   所以在现有的商业CASE工具，对于基于use case的SRS与FRS是结合的，并同时提供了一个二维交互图，可以很容易了解，哪些功能需求属于哪个用例，而哪个用例又会覆盖哪些需求。

恕我直言，我从来不相信所谓全面的深入，寸有所长，尺有所短，再是专家，也只会有自己的关注点。
扩展包含，是在处理用例间关系，描述系统结合性的重要组成部分，如果用例都只是单个单个，那么这个use case就弱化为最基本的FRS了。
只所以说“先画出界面，再写用例就好写多了”，是因为大多数客户或者需求提出人员，他们更能或者说更喜欢从直接的操作中知道系统分析人员对业务的分析和理解，并能找到和发现问题的关键。在需求分析阶段，UI与用例图所针对的对象是完全不同的，UI是针对客户的，而use case diagram是针对开发设计与测试人员的。如果相互混淆了，给客户看用例图，给开发设计测试人员看UI，就容易出现误导和问题了。

本来不想参与这个讨论，因为我本来准备写《胖子说uml》《胖子说用例》。但是我想等庄把他的那个文章写完再写我的，所以现在就简单的说说。
首先实际上存在两种uml，作为一种建模语言的uml，作为一种编程语言的uml。建模语言的uml是简单的，图示化的，普遍使用的。编程语言的uml是细节化的，复杂的，使用范围狭窄的。作为一种建模的语言，uml的各种图是有重要性的区别的，或者说是存在一个小的核心语言的——类图和顺序图。即便是作为一种编程语言，这两种图也可以满足大部分的需要。而类图其实也不需要完全的都去掌握，也是存在一个比较小的核心的。有关的内容可以参考《uml distilled》，特别是第三版。
这里有一个问题，就是uml是不是存在方法论喜好？在我看来是存在这样的趋势的——uml更加喜欢增量迭代。详细的论述这里就不做了，我只是说一个大概。uml是对象建模语言，而寻找对象、发现对象、分析对象、设置对象，是uml的核心关注点。采取一种顺序的，不反复的，一次性方向不可逆的方法，或者说瀑布的方法，使用面向对象技术，会是一件很别扭的事情。这样做就会把面向对象对于增量开发的支持所提供的能力抛弃。面向对象技术处理复杂情况的根本还就是对于增量开发的更好支持，如果不做增量，就看不出对象技术究竟更加优秀在什么地方。那些说uml的各种图会在不同的阶段重要程度不同的说法，至少是一种表达的错误。
uml的最大用途就是用来交流，而那些过于细节化的东西，往往会阻碍交流。同时如果使用太多的uml的不同图，也会对交流产生阻滞。

对于用例，主观上很多人并不很清楚，特别是国内，很少有客户知道用例。大家表述需求的普遍做法，是功能清单（实际上功能清单往往就是界面上的菜单和按钮）。这样的做法无疑如果不去关心客户究竟想做什么，只是为了完成软件会更加有效。而所谓先画界面，然后写用例的做法，无疑是对用例概念的忽视。用例所关注的无非是两点，谁参与了，他们为什么要参与（或者说他们的目标是什么）。使用用例可以把用户的需求，按照他们的目标进行条理化，而不是按照软件的功能去寻找用户的目标。你应该先确定你究竟想要什么，然后才能知道怎么得到它们。也就是说你应该先确定有那些用例，然后按照这些用例去确定究竟如何实现，并且验证那些目标是不是真的目标。同时我们也会发现，很多人使用用例在做着设计的工作，而不是分析的工作，而这恰恰不是用例所擅长做的。而用例图的作用恰恰是同用例的最初诉求有矛盾的，用例图往往关注于过程，而不是目标。即便作为开发人员，也更加应该关注于用户的目标，而不是过程。同时使用用例图来表示过程，本身就是不是很合适，其他diagram会做的更好。同时我们还应该注意，所谓的包含和扩展，往往带来的麻烦比其作用更大。不使用这两种技术，我看不出会收多大的损失，而且使用别的方法也可以完成它们的愿望。具体的情况，我会在今后作出详细的介绍，大家不用着急。

然也，姜还是老的辣。
实施上由于客户及现实的原因，和客户沟通上往往做不到使用用例建模，只好采取先画界面的办法，可是这样的结果出来后，除了最初和客户沟通，画界面的那个人之外，没有人能了解客户的业务是想干什么，甚至当时那个人都没意识到业务该是怎样的，于是后期只好被误导，走了弯路，如果一开始就使用用例来描述，情况会好很多。

算了，辩证法的东西对具体技术没什么用，空话还是别说了

这个和你划分或者说查看粒度有关

诚然用户看重UI这是目前事实，但认为这种状况不可改变就不去改变，把真正目的放一边不是专业的做法。

有些情况下，无法分清功能列表和用例的原因之一可能是因为没有划分好功能性需求和非功能性需求，在我看来，所有的功能性需求都可转换为用例，而非功能性需求（例如安全，多语言支持）就只能是作为非功能性需求来处理了。

oz6所说uml的方法论喜好倒是头一次听说，确实很有道理。

首先要承认确实如oz6说的那样，“那些说uml的各种图会在不同的阶段重要程度不同的说法，至少是一种表达的错误。”实际项目中我会将业务调研活动先铺开，这个阶段的任务和瀑布的过程基本上相同，然后是落实功能点、定义优先级、划分里程碑（版本迭代计划，一般2－3个月一个版本），这种过程可能和oz6的迭代过程有差异。做业务调研的时候我的看法是把工作做细，也多不了多少时间，企业的业务关系牵扯面比较多，只有了解了整体才有把握制定版本计划，这点可能和每个人的经验和项目环境有关。在迭代开发的阶段，业务文档是会随时进行变更和补充。

用例和功能清单，功能清单现在看来有两种说法，一种是基于业务目标和业务内容的功能点集合说明，一种是基于产品或者软件实现功能的详细定义，前者基于业务，后者基于实现的操作功能，我所说的功能清单是指第一种，功能清单应该是纯粹业务功能要求，而详细的业务功能描述应由其它文档进行说明。我觉得对功能清单的看法和oz6对用例的看法是一致的，只是名称不同，和用例图没有什么关系。