现在正在学UML,觉得它好复杂,那么多图,如果做一个系统的分析要画那么多图,是不是有点浪费时间!
------解决方案--------------------------------------------------------
我理解：UML只不过是一个工具,每个图及模型都有其自身表现的价值。用例图能展现需求，活动图能展现流程，时序图能展现职责调用过程......，使用UML对项目有没有价值该不该用或者用那些表现图，要看项目的实际情况：业务领域熟悉程度、需求变更稳定性、项目团队能力、组织项目管理水平等等。复杂多变存在风险的项目肯定预先需要进行系统需求分析，进行建模，建模当然需要使用建模语言及工具。
所以 浪费不浪费时间看你是否直接能清晰简单的识别出你做得东西，如果很简单那就是浪费，直接写代码就可以。
------解决方案--------------------------------------------------------
看实际情况，不是所有系统都要用UML。
UML是用来干什么的呢？只是一种建模的语言，可以作为开发方与客户方沟通的工具，可以对复杂的问题进行形象化的表达，可以在一定程度上解决项目组内人员交流的问题。那也就是说更适用于复杂的系统开发、不顺畅的客户沟通、多人员及人员流动性大的开发团队。对于简单的系统开发及人员沟通情况的话可以不需要使用UML。
------解决方案--------------------------------------------------------
如果模型简单，那么就没必要用UML表达，简单图表+文字说明即可。如果模型复杂，用UML表达会比较直观。
而且UML有个好处：UML是通用的建模语言，大家都能看懂。
------解决方案--------------------------------------------------------
基本上使用UML十分之一就足够。
UML早已经偏离了OO设计的主要目标，主要用来满足“各种各样”流派的需求，成了Rational赚取名声（而牺牲清晰性）的一个工具。
------解决方案--------------------------------------------------------
我觉得在XP中把USER CASE和故事板写好就行，在SCRUM中倒是可以多利用UML。当然，SCRUM中也要把backlog list搞定
------解决方案--------------------------------------------------------
并不是一个系统里面要把所有的图画出来
不同的系统可能需要用到不同的图，每种图都有它独特的地位
个人认为比较重要的几种图：用例，类图，状态，时序，活动
------解决方案--------------------------------------------------------
看你拆分的粒度。
UML可以做概要设计，也可以做详细设计。还可以做需求...
------解决方案--------------------------------------------------------
还蛮好用的
至少图不难懂
再来就是那些就像英文单字一样
会的都会,是统一的语言