[TL][开发][UML]UML的实用价值
郑培祥
--
此致
敬礼！
郑培祥
jun lin
公司用ER图画数据关系，
流程图画业务流程，
这个东西只有在给别人看的时候才有用，
自己的话有个概念，画在纸上面就好了。
Shuo Chen
为什么你觉得“大程序最好使用UML”呢？用了有什么好处？哪个大程序在用？
你的“UML有实用价值”这个印象是如何形成的？看书还是听老师讲？
赵永旺
--
------------------------------------------------------------
Name:赵永旺
QQ:251438118
MSN:yinzh...@hotmail.com
E-mail:yongwa...@gmail.com
Address:湖北省武汉市武昌珞珈山信息管理学院
Shuo Chen
On Nov 19, 9:55 pm, 赵永旺 <yongwang.z...@gmail.com> wrote:
> 呵呵，目前我们公司在做设计的时候还是会用到的。不过有一点不好的是，在开发实现的后期，由于各种原因吧，会对原始设计做一些更改，对这些原始文档的同步更新做得不够好，导致这些设计文档的可使用性大大降低。
>
> 2009/11/19 Shuo Chen <giantc...@gmail.com>
>
>
>
> > "国外公认非常有用"这个结论是怎么得出的？你知道哪些国外公司在用？它们用到什么程度？
> > 为什么你觉得"大程序最好使用UML"呢？用了有什么好处？哪个大程序在用？
> > 你的"UML有实用价值"这个印象是如何形成的？看书还是听老师讲？
> > 郑培祥 wrote:
> > > 大家好，
> > > 和大家讨论一个问题，UML，国外公认非常有用，从形形色色的不断升级的工具（bouml
> > > ,rose,staruml)就可以看出，但是请问大家在实际工作中用到的多少呢？
> > > 我的理解：
>
> > 大程序，需要保证的程序，最好使用，但是小程序，没有太多难度的程序，一般不需要使用，而中等程序，可以在关键部位使用一种工具（状态图，类图...)
> > > 我有几个问题不明白：
>
> > 我发现公司很多不用的，不仅仅是小公司不用，一些中等公司也不使用，真是非常奇怪的事情，我是个学生，对公司的事情也不是很了解，这些事情是听说，或者不同单位实习的同学讨论得出的。
> > > 那么大家都是在什么情况下使用呢，在什么规模的任务下才会用呢？大家最常使用的部分是那几部分呢？
>
> > > --
> > > 此致
> > > 敬礼！
> > > 郑培祥
>
> --
> ------------------------------------------------------------
> Name:赵永旺
> QQ:251438118
> MSN:yinzhao0...@hotmail.com <MSN%3Ayinzhao0...@hotmail.com>
> E-mail:yongwang.z...@gmail.com <E-mail%3Ayongwang.z...@gmail.com>
> Address:湖北省武汉市武昌珞珈山信息管理学院
jun lin
开头的时候要分析各种因素，方案改动比较大。用纸和笔最快。
但是方案定了后，开发需要统一，就作出一个UML图保存和交流。
但是后期开发再做改动，不改uml造成文档和代码同步，改uml。。真是累死人。
Kenny Yuan
（嗯，我也学一学新华社记者，也来对中国人搞一搞种族歧视）
“国外公认非常有用”这个结论是怎么得出的？你知道哪些国外公司在用？它们用到什么程度？
为什么你觉得“大程序最好使用UML”呢？用了有什么好处？哪个大程序在用？
你的“UML有实用价值”这个印象是如何形成的？看书还是听老师讲？
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL1: http://csbabel.wordpress.com/
URL2: http://blog.csdn.net/yuankaining/
lcgong
sunskyor sunskyor
Evan Yu
2009/11/17 郑培祥 <peixian...@gmail.com>:
郑培祥
--
此致
敬礼！
郑培祥
zhaoren liu
--
Sent from my mobile device
Huang
--
Regards,
Chao
xiliu tang
AlexNeko
唐继斌
Huang
Robert Wang
Fuzhou Chen
我认为这里的关键不是在项目中怎么画图，而是该用什么工具。要是楼主光打算拿UML图当文档，可能是走偏了。
就我所知，Rational Rose那个东西最大的卖点从来都不是画UML，而是通过UML生成各个平台上的代码框架。正常用Rose的方法是架构师先画图，再指定要生成的语言和平台是什么，比如基于Windows/C++，或者是Linux/Ada，Rasional Rose就能直接生成框架代码和project文件/Makefile，拷贝到对应系统上就可以编译。当然这时候生成的只是一大堆空函数，接下来就要召唤代码工人写代码了。Rose能卖出天价，靠的就是数目庞大的语言/平台代码生成支持。
IBM那边也有一些试图做反向生成的项目，就是把别的项目里已经存在很久的代码拿来分析然后重新生成UML的类图甚至控制流图。我不知道别的UML工具怎么样，但在学校的时候我一个很敬重的老师和IBM合作，就是这种双向转换的Rational Rose插件，平时也聊聊，多少知道一点。
顺便发一句牢骚，如果就拿UML画画，那Rose即使不是最差的，也可以算是最差的之一。我四年前还在学校的时候凑热闹试了试，还不如用Visio美观呢。
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
lcgong
UML用在白板上，还是可以，常见的也是这种。但UML自称language，如果真的把它当作语言而完整用到一个工程或项目中，或许会受伤。
这四五年来，不知道UML工具或平台在code generation、round-trip engineering相关技术上有什么大的飞跃，如果没有那就需要当心了。应用UML模型后，将会被迫维护模型树和代码树，它们之间一致性是否还和以前那么脆弱、效率低下。如RUP所述用例驱动、迭代开发、架构中心，模型是否真的可以驱动这一切呢？即使拥有了重构工具，敢不敢每次迭代后进行重构？的确应用UML需要大量资金投入，花费不但在工具和培训上，甚至还要雇用更多人手来确保变更可以追溯，应对那繁琐的映射细节。直到有一天回过神来决定砍掉那棵模型树，这绝对是一场地震，需要勇气。
定期的重构，清晰的依赖关系和命名空间（包与类），普遍的设计模式应用，使得一看见名字就猜到是啥结构是啥用途，关注框架时能够关注框架，关注算法时能够关注算法，这或许要比画几图更为实效。
Shuo Chen
说道“用UML”，如果指的是在设计阶段用类似UML（可以手画，也可以不严格遵循UML语法）的类图、时序图、协作图打打草稿，那么我们也用过。这种
图，说是UML图也行，说是框图也行，无非就是几个框框几条线。
如果指的是时刻保持代码与图的同步，那么我们没有用过。我也不知道谁在这么用。同时我怀疑这样付出的成本能不能抵得上收益。
另外，我不认为UML能精确表述，虽然它号称如此，图形总没有代码明晰。快速排序用时序图怎么画？有没有比代码更容易懂？新功能也是先加到语言上，比
如 C# 的 attribute，用 UML 怎么表述？delegate 呢？Java 7 即将加入的 closure 呢？
Shuo Chen
发的后退？
如果UML完全能从代码自动生成，那它似乎也没有单独存在的意义了。
missdeer
准备好，才能提交到代码库中，而且这之前之后都是反复评审、审查，成本是大，不过如果非项目组成员要参考时，确实极有帮助。最近一年来，公司开始推敏
捷，文档撰写和维护的工作量也许略有减少。
On Nov 23, 11:04 am, Shuo Chen <giantc...@gmail.com> wrote:
> 要是我没记错的话，Rational Rose 自从 2003 年起就没有再更新。
> 说道"用UML"，如果指的是在设计阶段用类似UML（可以手画，也可以不严格遵循UML语法）的类图、时序图、协作图打打草稿，那么我们也用过。这种
> 图，说是UML图也行，说是框图也行，无非就是几个框框几条线。
> 如果指的是时刻保持代码与图的同步，那么我们没有用过。我也不知道谁在这么用。同时我怀疑这样付出的成本能不能抵得上收益。
> 另外，我不认为UML能精确表述，虽然它号称如此，图形总没有代码明晰。快速排序用时序图怎么画？有没有比代码更容易懂？新功能也是先加到语言上，比
> 如 C# 的 attribute，用 UML 怎么表述？delegate 呢？Java 7 即将加入的 closure 呢？
>
> 郑培祥 wrote:
> > 呵呵，淡定淡定
>
> > 我是猜的，
> > 因为ibm花了大价钱做ROSE，说明这个东西有市场，而且，有很多uml的工具一直在更新，说明这个东西有需求，再说，中国的开发商，我见过的，很多连测试人都很少，很多就找个人点一点，联想来，uml在国内用的应该会很少。
>
> > uml我觉得有些时候还是很有用的，在很多复杂的情况，脑子确实算不过来，东西多了，想起这块，忘了那块，纸上写写画画更新不不方便。这样我觉得uml肯定有实用的价值。
> > 但是我不确定，所以到组里问一问大家的使用情况
>
> > 至于用词嘛，兄弟，不要那么紧张，这不是paper，往往能把问题说清楚就发出去了，不要太深究啦
> > 2009/11/19 Shuo Chen <giantc...@gmail.com>
missdeer
>
有时候看UML比直接看代码直观~
f yt
Alex Lee
UML本身对于便于交流的作用还是值得肯定的。
另外，UML只不过是架构师或设计师的表达思想的工具，便于交流而已，不要抬得过高。
最后，软件设计的质量关键因素还是人，工具永远只是辅助，可以提倡，但不能喧宾夺主。
--
Nick Name:cayenne
Website:http://hi.csdn.net/forever_feng
Blog: http://blog.csdn.net/forever_feng
Alex wang
话说回来，一般我看到的情况是做项目的对这个玩意不太感冒，比如我就几乎没用过，用到的也是在最后提供给客户文档的时候作为一个补充的“美化”材料而已；而作产品的似乎用的更多，因为人家的产品的生命周期不一样。所以从这个角度说，在产品中用ＵＭＬ应该是让设计更加清晰和可视了，或者说更规范了，应该是好事。
Alex wang
什么叫制度（这里是指类似ＵＭＬ这样的工具）？无非就是防范那些意外的事情如果一旦发生不会带来灭顶之灾，那你为了得到这个好处是不是应该付出代价？ 当然了，一方面是金钱的代价，一方面是维护它的代价。如果想要人家给你带来的好处，另一方面又不愿意承受应该付出的成本，这个就有点不合适了。
所以，这玩意好不好？ 需要的人就是好的，不需要的人就不好，各取所需。
Cheng, Long
见过用UML的，拿来忽悠忽悠客户而已。
xiliu tang 写道:
> 根据我的经验，UML实际上没什么用，大程序，小程序都不用，据说在做ERP类似
> 的行业会比较有用。。。
>
> 2009/11/19 Shuo Chen <gian...@gmail.com <mailto:gian...@gmail.com>>
>
> “国外公认非常有用”这个结论是怎么得出的？你知道哪些国外公司在用？它
Alex wang
我以前在一家公司，很多客户的项目后来再打电话过来让开发人员维护时居然公司说，“这个项目是我们做的吗？”的搞笑新闻
程序员都不愿意写文档，这个是事实，但是一个整体不可能光靠程序员的code延续下去，需要的是纪律，纪律说白了就是对人不相信，先假设你是一个混蛋，可能给公司带来不确定的因素，然后，一切按流程做事。至少这样是安全的，阿朱的博文里提到的方式可能更好，就是有专门的一些角色来做这个事，比如测试人员之类，这样程序员也不至于太分心，比较好。
写比不写好，有文档比没有文档好，规范比不规范好，这个是底线。
DebuggingNow
技术博客:http://debuggingnow.com
我的豆瓣:http://www.douban.com/people/baiyanhuang/
Shuo Chen
（说错了还请指正）
楼主觉得国外的人在用，
Huang觉得搞外包的人在用，
xiliu tang认为"在做ERP类似的行业会比较有用"，
f yt认为"应该在团队沟通和协作上比较有用"，
Alex wang认为"作产品的似乎用的更多"，
这算不算"UML迷思"？
我做项目（说产品也行，上线一年以来已经更新了多次）的时候不用，做ppt的时候偶尔用一用 :)
On Nov 22, 9:53 pm, Alex wang <idea.w...@gmail.com> wrote:
> 我是一直做java的，以前刚入行的时候对UML也有点顶礼膜拜，觉得只有大拿才能摆弄这个玩意，不过这么多年过去以后还是觉得这个玩意确实不是一般的公司能玩的，我想大部分公司都是一般公司吧，那些有钱用不掉的，资源很强悍的，人家总要给自己往"先进"上贴，至于是不是真先进，大家掰扯不清楚，因为毕竟就是一工具，既然是工具就有人喜欢有人不喜欢，你不能说小李飞刀的刀和张飞的刀到底哪个厉害。似乎说的有点远了，其实画UML图本身并不是一个坏事，你就是一个比较简单的业务逻辑画出来它也是让你思考了一次，就跟写文章一样，让你思考的事当然是好的事情，但是仅此而已，你把它当做思考的过程和辅助手段可能更好，而不要上升到一个什么包治百病的玩意，或者什么框架，或者什么什么语言级别的，那是不是忽悠也难说了。
>
> 话说回来，一般我看到的情况是做项目的对这个玩意不太感冒，比如我就几乎没用过，用到的也是在最后提供给客户文档的时候作为一个补充的"美化"材料而已；而作产品的似乎用的更多，因为人家的产品的生命周期不一样。所以从这个角度说，在产品中用ＵＭＬ应该是让设计更加清晰和可视了，或者说更规范了，应该是好事。
>
> 2009/11/22 lcgong <lcg...@gmail.com>
>
> > 我反而认为Shuo Chen的反问已经回答楼主的问题了，只要一一回答，至少就会产生对UML光环的质疑。
>
> > UML用在白板上，还是可以，常见的也是这种。但UML自称language，如果真的把它当作语言而完整用到一个工程或项目中，或许会受伤。
>
> > 这四五年来，不知道UML工具或平台在code generation、round-trip
> > engineering相关技术上有什么大的飞跃，如果没有那就需要当心了。应用UML模型后，将会被迫维护模型树和代码树，它们之间一致性是否还和以前那么脆弱、效率低下。如RUP所述用例驱动、迭代开发、架构中心，模型是否真的可以驱动这一切呢？即使拥有了重构工具，敢不敢每次迭代后进行重构？的确应用UML需要大量资金投入，花费不但在工具和培训上，甚至还要雇用更多人手来确保变更可以追溯，应对那繁琐的映射细节。直到有一天回过神来决定砍掉那棵模型树，这绝对是一场地震，需要勇气。
>
> > 定期的重构，清晰的依赖关系和命名空间（包与类），普遍的设计模式应用，使得一看见名字就猜到是啥结构是啥用途，关注框架时能够关注框架，关注算法时能够关注算法，这或许要比画几图更为实效。
>
> > 2009/11/19 Huang <hjbol...@gmail.com>
>
> >> 不要连珠炮的一顿反问吧, 这样有点火药味.
> >> 楼主是问问题, 不是求问题.
>
> >> IBM一直在做rational的那套东西就说明了它的用处, 个人感觉, 外包用的比较多吧.
> >> 当然国内那些很小的外包公司是不会用这个的. 大家都是office流. 我同学在大连做外包的时候就这个感受.
> >> 一个标准化的概念而已.
>
> >> 2009/11/19 Shuo Chen <giantc...@gmail.com>
missdeer
现在各种设计工具某些程度上都是为了减少工作量和增强可传播性，但不可避免的是由于技术上的一些限制，还不能达到更贴近人类大脑的思维方式和习惯。其实
通常的人们做笔记的方式也有这个问题，所以托尼布赞发明了思维导图，只不过现在又有很多画思维导图的软件，真是本末倒置，除非是用手写笔去画。
On Nov 19, 8:14 pm, AlexNeko <alexnek...@gmail.com> wrote:
> UML的思想很好；但不喜欢用UML软件、喜欢白板和笔～
张慧聪
Xorg社区也不用吧
我是想说这种理念对于有一群人(而且绝对是高手)来说是没用的吧。
我的印象里就是，这玩艺儿就是一种把软件工业化的思路，让每个人都做尽可能简单的事，向熟练工人靠拢。但编程也是可以充满着刺激而精彩的创造的，这时候可能就不会去用UML了。
文艺型程序员+围棋偶饭+SC剩菜饭+前科幻迷+数学习饭
missdeer
但现实是对整个程序员群体来说，真正的高手是少数，而新手和普通熟手则占大多数，既然有用，能减少负担，为什么不用？
东方不败不用普通刀剑，因为她（？）用绣花针都有巨大威力，难道大多数普通人可以弃用刀剑了？
图灵刘江
UML用处肯定有，至少OO书里都在用它描述设计。
但是说实话，UML的价值的确是可讨论的。不仅是现在，如果大家读过
Robert Martin的《敏捷软件开发》（C#版）（图灵出的那本，Java/C++版
好像没有讲UML）的话，就会发现大叔讲UML的时候往往是这样的套路：
XXX图啊，我没有用过……
XXX图啊，我只在……情况下才用
……
印象中UMLChina的潘加宇也说过许多UML图一般都用不上的话。
某种意义上，往复杂化方向发展的UML 2.0标准进一步削弱了UML的价值。
Google一下”is UML useful“会有很多有意思的结果。
Bertrand Meyer的讽刺文章：
http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html
Joel谈软件网站里的讨论：
http://discuss.joelonsoftware.com/default.asp?joel.3.202235.27
名博CodeBetter：
http://codebetter.com/blogs/jeremy.miller/archive/2006/07/05/147119.aspx
还有这个：
http://www.codingthearchitecture.com/2008/04/03/is_uml_on_the_way_out.html
StackOverflow上类似的讨论：
http://stackoverflow.com/questions/18803/is-uml-practical
jinhu wang
redsea
UML 应该是到了 PPT 的阶段比较有用.
jinhu wang
Li Yang
但是在一些公司，他们的代码是给别人用的，这个时候就有一堆人专门负责写程序文档UML之类的，然后和代码一起交付给对方，不过这些工作也都是在代码接近完成情况下才会做，也就是说，现有的代码，后有的UML图。
所以我觉得，这个东西现在的情况是教学的意义大于实用意义，就跟SICP里面的scheme一样，只是理解软件工程过程中的一种工具而已
--
While(!success=try())
Fei Yan
看到这些东西的时候，就会感觉比和印度阿三磨嘴皮效率不知要高多少倍，心里也有底的多。
Serenade
后来实际操作中发现，绝大多数情况下，不可能最初的UML设计就是完善可行的，往往代码写到一半了需要修改结构应对问题，这个时候退回去uml重新设计，-
-； 是8行的
几次下来，放弃了UML->Coding的顺序，改成了直接Coding，辅以UML描述程序撰写文档；啊，对了，一旦项目赶进度，那么UML。。。就拜拜了
UML现在在我而言，更像是个与思维导图类似的用于程序描述的工具，反倒是像测试驱动开发这种东西，成了开发习惯之一，不知道有没有同样感受的
sagasw
让我想起一个twitter的段子。
某人到了美国，对鬼子介绍中国说：中国的底层官员比较腐败，但是高层领导还是为人民服务、很不错的。鬼子回他一句：
How do you know?!
这四个字是大杀器啊！
sagasw
如果说非uml不能解释逻辑，难不成做业务的也都要学uml？
只是个工具，莫当真。
Fei Yan
UML作为一个交流工具的价值还是挺大的，毕竟符号都很简洁、易懂。
jinhu wang
liyun peng
UML还是非常有用的，尤其在做项目的时候，画时序图，类图，能够很容易把思路理清楚，而且方便交流。上面这两点优点便是使用UML最根本的驱动力，也因为思路清楚有助于自己开发，交流方便有助于团队开发，所以，UML的价值是非常巨大的，有时间就多学习使用它，平时工作的时候，也可以画画，当然我个人感觉要比在纸上画的要快，不然在纸上画也是很好的！
2009/11/18 郑培祥 <peixian...@gmail.com>
UMLChina
我从事UML相关的研究已经10年，UML建模是很能为软件组织带来利润的东西，背后的知识更是博大精深。
UML属于软件工程范畴，软件工程和计算机科学的不同是和人相关：软件是"卖"给"人"的，软件是由"人"开发的。人的心理难以捉摸（所以需要需求技
能），人的大脑处理复杂性时有速度和容量的局限（所以需要设计技能）。
大家可以参看以下资料了解一些我的心得，是现在发行的书籍上所没有的：
http://www.mmmbook.com/umlchina_01_overview.pdf
http://www.mmmbook.com/umlchina_03_bm.pdf
http://www.mmmbook.com/umlchina_04_req.pdf
http://www.mmmbook.com/umlchina_11_tips.pdf
特别是第一个和最后一个。
希望能回答大家心里的一些疑惑。
我现在在出差途中，先作此短复，以后我会回来一一回答大家的具体问题。
如果您在杭州或华东地区，还可以来参加我们的12月12-13日杭州非盈利公开课
http://www.umlchina.com/training/course091212.htm
课上会解答您的所有疑惑。
On Nov 18, 9:27 am, 郑培祥 <peixiang.zh...@gmail.com> wrote:
> 大家好，
> 和大家讨论一个问题，UML，国外公认非常有用，从形形色色的不断升级的工具（bouml
> ,rose,staruml)就可以看出，但是请问大家在实际工作中用到的多少呢？
> 我的理解：
> 大程序，需要保证的程序，最好使用，但是小程序，没有太多难度的程序，一般不需要使用，而中等程序，可以在关键部位使用一种工具（状态图，类图...)
> 我有几个问题不明白：
>
> 我发现公司很多不用的，不仅仅是小公司不用，一些中等公司也不使用，真是非常奇怪的事情，我是个学生，对公司的事情也不是很了解，这些事情是听说，或者不同单位-实习的同学讨论得出的。
He Dan
Kevin xue
说到底，其实就是一种标准化的沟通方法，作用上和汉语英语这样的东西没有什么太大区别－－都是让别人理解自己。
我入行浅，就个人观点来看，早期能够设计出一个完善的UML图是十分困难甚至是不可行的。这样必然会增加后期对UML的维护成本。我觉得比较好的方法是：
一，极度精简的设计，当然可以用UML等来实现。
二，编码进行实现。肯定会遇到问题，容易解觉得就解决，不容易解觉的先使用某种比较tricky的方法解决
三，通过测试，确保可用性等指标
四，重构＋完善一些必要的说明资料（当然也可以包括UML图等，不过不管怎样，维护一套UML图的成本在我看来，有点太大了）
--
BR
Kevin
allen xu
的一种语言，语言其实就是一种工具，用不用在你，用的好不好也在于你。UML这个东西是很灵活的，不一定非要生搬硬套UML的使用规则，也不一定非要用
ROSE来画UML图，用Viso、office、笔纸都可以画。UML更侧重与在设计和交流上，我想没有哪个公司会将系统的所有代码都映射为UML，
而且不断去维护的，除非钱多得没处花了，这又是另外一个话题，关于质量和成本的关系，质量和成本是成上升曲线的关系，成本投入越多，质量肯定越高，但是
质量的提升变化确是越来越小的，所以我们要把握成本和质量的一个平衡点，适当的使用一些软件工程过程和工具。
jinhu wang
UMLChina
UML是目前软件建模的标准语言，背后是一套很有用的需求（即，提升销售）和设计（即，降低成本）技能集，大大小小的软件组织都在有意识无意识地使用这
个技能集里的一部分，其中用得最多的是用例、类图、序列图、活动图和状态图。只要有追逐利润的需要，这些技能都是用得着的。
市场没有"小软件"、"小项目"，更没有"没有难度的软件"。要在市场立足，每种产品肯定需要有自己的立身之道，可能是大，可能是精。"市场"、"利
润"不是狭义的，赚取的可以不是钞票，而是学术地位、官职、名声...
UMLChina
http://www.umlchina.com/Tools/umltools.pdf
On Nov 23, 11:04 am, Shuo Chen <giantc...@gmail.com> wrote:
> 要是我没记错的话，Rational Rose 自从 2003 年起就没有再更新。
> 说道"用UML"，如果指的是在设计阶段用类似UML（可以手画，也可以不严格遵循UML语法）的类图、时序图、协作图打打草稿，那么我们也用过。这种
> 图，说是UML图也行，说是框图也行，无非就是几个框框几条线。
> 如果指的是时刻保持代码与图的同步，那么我们没有用过。我也不知道谁在这么用。同时我怀疑这样付出的成本能不能抵得上收益。
> 另外，我不认为UML能精确表述，虽然它号称如此，图形总没有代码明晰。快速排序用时序图怎么画？有没有比代码更容易懂？新功能也是先加到语言上，比
> 如 C# 的 attribute，用 UML 怎么表述？delegate 呢？Java 7 即将加入的 closure 呢？
>
>
>
> 郑培祥 wrote:
> > 呵呵，淡定淡定
>
> > 我是猜的，
> > 因为ibm花了大价钱做ROSE，说明这个东西有市场，而且，有很多uml的工具一直在更新，说明这个东西有需求，再说，中国的开发商，我见过的，很多连测试人-都很少，很多就找个人点一点，联想来，uml在国内用的应该会很少。
>
> > uml我觉得有些时候还是很有用的，在很多复杂的情况，脑子确实算不过来，东西多了，想起这块，忘了那块，纸上写写画画更新不不方便。这样我觉得uml肯定有实-用的价值。
> > 但是我不确定，所以到组里问一问大家的使用情况
>
> > 至于用词嘛，兄弟，不要那么紧张，这不是paper，往往能把问题说清楚就发出去了，不要太深究啦
> > 2009/11/19 Shuo Chen <giantc...@gmail.com>
>
> > > "国外公认非常有用"这个结论是怎么得出的？你知道哪些国外公司在用？它们用到什么程度？
> > > 为什么你觉得"大程序最好使用UML"呢？用了有什么好处？哪个大程序在用？
> > > 你的"UML有实用价值"这个印象是如何形成的？看书还是听老师讲？
> > > 郑培祥 wrote:
> > > > 大家好，
> > > > 和大家讨论一个问题，UML，国外公认非常有用，从形形色色的不断升级的工具（bouml
> > > > ,rose,staruml)就可以看出，但是请问大家在实际工作中用到的多少呢？
> > > > 我的理解：
>
> > > 大程序，需要保证的程序，最好使用，但是小程序，没有太多难度的程序，一般不需要使用，而中等程序，可以在关键部位使用一种工具（状态图，类图...)
> > > > 我有几个问题不明白：
>
> > > 我发现公司很多不用的，不仅仅是小公司不用，一些中等公司也不使用，真是非常奇怪的事情，我是个学生，对公司的事情也不是很了解，这些事情是听说，或者不同单位-实习的同学讨论得出的。
> > > > 那么大家都是在什么情况下使用呢，在什么规模的任务下才会用呢？大家最常使用的部分是那几部分呢？
>
> > > > --
> > > > 此致
> > > > 敬礼！
> > > > 郑培祥
>
> > --
> > 此致
> > 敬礼！
> > 郑培祥- Hide quoted text -
>
> - Show quoted text -
UMLChina
以Linux上千万行代码不用面向对象不用UML...不必奇怪。这同样适用于很多开源非开源的基础设施项目。因为负载低，所以基础设施级别的复用比较
容易。
很多能够带来利润的系统"负载"比较高，除了核心领域的知识，还要依赖于其他非核心域（包括Linux、Oracle...）的知识。而且，核心域并没
有那么多人去研究，例如，没有看到过一本这样的书，把一家医院的流程，各种业务对象，用某种方法（彩色UML建模也好，以前的数据流图＋ER图也好）研
究得透透的。
要是让Linus（或Anders...）负责设计一个全国的税务系统，我不认为他们就一定能胜任。
编程是创造的最后一步，编程之前的思考才是创造的根源。UML背后的业务建模和需求技能可以让我们获得"严肃的创造力"－－通过艰苦的调研和严肃的思考
获得真正的创新。
On Nov 24, 7:10 pm, 张慧聪 <zhcfree...@gmail.com> wrote:
> linux的开发团队不用UML吧
> Xorg社区也不用吧
> 我是想说这种理念对于有一群人(而且绝对是高手)来说是没用的吧。
> 我的印象里就是，这玩艺儿就是一种把软件工业化的思路，让每个人都做尽可能简单的事，向熟练工人靠拢。但编程也是可以充满着刺激而精彩的创造的，这时候可能就不-会去用UML了。
>
> 文艺型程序员+围棋偶饭+SC剩菜饭+前科幻迷+数学习饭
UMLChina
找一个有多年工作经验的Java程序员出来，他也会说，Java的这个这个啊，我没有用过，Java的那个那个啊，我没有用过...
顺便说Robert Martin，他把他的书命名为《敏捷软件开发》，其实说的主要是面向对象的设计原则，而且是很多先行者的成果。此书的命名造成了
很大误解，似乎这些东西是敏捷开发带来的。要是我们返回去看Peter Coad,Ed Yourdon, Odell, Wirfs-Brock、
Booch...等人的著作，可能就会发现他们更加严谨，更加朴素。
On Dec 2, 3:47 am, 图灵刘江 <liuj.tur...@gmail.com> wrote:
> 这是一个我一直想拿出来大家讨论的问题。
>
> UML用处肯定有，至少OO书里都在用它描述设计。
>
> 但是说实话，UML的价值的确是可讨论的。不仅是现在，如果大家读过
> Robert Martin的《敏捷软件开发》（C#版）（图灵出的那本，Java/C++版
> 好像没有讲UML）的话，就会发现大叔讲UML的时候往往是这样的套路：
> XXX图啊，我没有用过......
> XXX图啊，我只在......情况下才用
> ......
>
> 印象中UMLChina的潘加宇也说过许多UML图一般都用不上的话。
>
> 某种意义上，往复杂化方向发展的UML 2.0标准进一步削弱了UML的价值。
>
> Google一下"is UML useful"会有很多有意思的结果。
> Bertrand Meyer的讽刺文章：http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page....
>
> Joel谈软件网站里的讨论：http://discuss.joelonsoftware.com/default.asp?joel.3.202235.27
>
> 名博CodeBetter：http://codebetter.com/blogs/jeremy.miller/archive/2006/07/05/147119.aspx
>
> 还有这个：http://www.codingthearchitecture.com/2008/04/03/is_uml_on_the_way_out...
>
> StackOverflow上类似的讨论：http://stackoverflow.com/questions/18803/is-uml-practical
Changli Wang
--
Best regards!
-------------------
王长历
E-mail:changli...@gmail.com
Tel:15872429504
Address:华中科技大学东七楼615软设组
张慧聪
jing wang
Eric.Wang
UML太阳春白雪，没法用。
word文档+code代码，才是最实用的。其他都是扯淡。
居振梁
而且，前面才说了“没有银弹”的，不用迷信课程，在学生讨论“相对于编程语言，软件工程这些东西才是不会变的”的时候，最好先明确一下，那些东西的具体应用范围。
我也是未参加工作 这学期学了一个理论课 叫软件项目管理 是IBM的rational rose。严格按照如软件开发流程，我觉得UML能给节省的资源是很可观的。在学校里写的小东西是没有用过UML的，但是我想以后接触的项目，大中型的，基本都是需要UML的
--
战斗暴龙：理论由自己理论，由这理论演绎实践；实践由自己实践，由这实践归纳理论。事事都理论+实践太累了。
http://wargrey.yo2.cn [黑客精神；团队精神；清心寡欲；像孩子一样思考]
http://wargrey.blogspot.com [BY-BLOG；自然语言试练场]
http://juzhenliang.blogspot.com [中文译出]
jinhu wang
jinhu wang
Shuo Chen
盘，就知道我在说什么:)
jinhu wang
Shuo Chen
Jerry
但，我时常用到UML。
UML，强调了Language，而既然是Language，核心目的只有一个：交流。
我的观点：UML为设计(主要是OO设计)，思想表达，提供了统一的语汇。
佐证：我看的很多书中都采用UML来表达设计，比如《企业应用架构设计》，《修改代码的艺术》，《设计模式》等等。
既然是语言，要通过语言进行交流，前提是：交流双方都应该听得懂这门语言。
只会说英语的人和只会说汉语的人----虽然都有语言----但无法交流。
记得周爱民在《大道至简》中有一句反问，打到了滥用UML的要害：业务人员/用户不懂C语言，难道他们就懂UML？
On Nov 18, 9:27 am, 郑培祥 <peixiang.zh...@gmail.com> wrote:
> 大家好，
> 和大家讨论一个问题，UML，国外公认非常有用，从形形色色的不断升级的工具（bouml
> ,rose,staruml)就可以看出，但是请问大家在实际工作中用到的多少呢？
> 我的理解：
> 大程序，需要保证的程序，最好使用，但是小程序，没有太多难度的程序，一般不需要使用，而中等程序，可以在关键部位使用一种工具（状态图，类图...)
> 我有几个问题不明白：
>
> 我发现公司很多不用的，不仅仅是小公司不用，一些中等公司也不使用，真是非常奇怪的事情，我是个学生，对公司的事情也不是很了解，这些事情是听说，或者不同单位实习的同学讨论得出的。
alsor zhou
又提出另外一种可能， UML只是为了专业的人和非专业的人进行交流使用的？专业的人之间交流是否用大白板画图更专业些，也就是一个中国程序员和阿三程序员貌似用Chinish和Indish也可以交流吧，不存在完全鸡同鸭讲的情况。
------
@veiz : Design is making function beautiful.
Gtalk: alsor...@gmail.com
LinkedIn: http://www.linkedin.com/in/veizhou
UMLChina
所以它只是在"软件开发人员"里面的统一（就像五线谱在音乐工作者里面的统一）。软件开发的复杂性相当于整个宇宙对计算机的映射，怎么能寄望婴儿、非洲
人，亚洲人，军人，80后，残疾人....懂得同一门语言？
/*
真正需要和涉众交流的内容只有一个：涉众利益，即涉众希望什么，我担心什么（就像音乐的听众觉得好听，不好听，悲伤，还是欢喜）。不是需求，也不是设
计。
而和涉众交流的媒介是模型的各种视图，而不是模型本身，例如给大领导看ppt，给中层干部看他喜欢的格式的文档，给一些的操作员看界面原型等等，也许有
时涉众根本不喜欢看任何东西，只愿意通过"谈话"这种视图来交流。
*/
我历来把UML背后的这些技能称为一把"烂柴刀"，砍死人狼是不够的，但是有这把烂柴刀在手，可以让人狼先吃掉赤手空拳的竞争对手。就像我们活在世上，
挣钱比同龄人多，活得比大多数人长一些，身体比大多数人好一些，就是成功了。我们是和周围的人比，不是和上帝比。
欢迎大家有机会带着项目来上我的非盈利公开课，我会用您的项目来向您展示UML背后思考的力量，并解答您的各种疑惑。
http://www.umlchina.com/training/course091212.htm
杭州12月12-13日UML非盈利公开课
http://www.umlchina.com/training/course091221.htm
北京12月21-22日UML非盈利公开课
近期DNS出现问题，导致有地方不能访问UMLChina。如果您不能访问以上页面，请在
http://www.peoplewarecn.com/course091212.doc
http://www.peoplewarecn.com/course091221.doc
下载以上页面的doc版本查看
如果您有空，麻烦回复告诉我们不能访问的情况，接入商是哪一家，如果能够附上tracert www.umlchina.com的屏幕就更好了。多谢！
On Dec 8, 8:35 am, Jerry <jerry.chou...@gmail.com> wrote:
> 我平时并不写UML，至少很少写规范的UML。
> 但，我时常用到UML。
>
> UML，强调了Language，而既然是Language，核心目的只有一个：交流。
>
> 我的观点：UML为设计(主要是OO设计)，思想表达，提供了统一的语汇。
> 佐证：我看的很多书中都采用UML来表达设计，比如《企业应用架构设计》，《修改代码的艺术》，《设计模式》等等。
>
> 既然是语言，要通过语言进行交流，前提是：交流双方都应该听得懂这门语言。
> 只会说英语的人和只会说汉语的人----虽然都有语言----但无法交流。
>
> 记得周爱民在《大道至简》中有一句反问，打到了滥用UML的要害：业务人员/用户不懂C语言，难道他们就懂UML？
>
> On Nov 18, 9:27 am, 郑培祥 <peixiang.zh...@gmail.com> wrote:
>
>
>
> > 大家好，
> > 和大家讨论一个问题，UML，国外公认非常有用，从形形色色的不断升级的工具（bouml
> > ,rose,staruml)就可以看出，但是请问大家在实际工作中用到的多少呢？
> > 我的理解：
> > 大程序，需要保证的程序，最好使用，但是小程序，没有太多难度的程序，一般不需要使用，而中等程序，可以在关键部位使用一种工具（状态图，类图...)
> > 我有几个问题不明白：
>
> > 我发现公司很多不用的，不仅仅是小公司不用，一些中等公司也不使用，真是非常奇怪的事情，我是个学生，对公司的事情也不是很了解，这些事情是听说，或者不同单位-实习的同学讨论得出的。
> > 那么大家都是在什么情况下使用呢，在什么规模的任务下才会用呢？大家最常使用的部分是那几部分呢？
>
> > --
> > 此致
> > 敬礼！
jinhu wang
杨腾飞
偶尔也会用到，但只是用到部分的图，不会全用。作为分析时的辅助工具吧，但也不一定要用Rose等，在白板上画画也行，理清思路就好。
根据我的经验，UML实际上没什么用，大程序，小程序都不用，据说在做ERP类似的行业会比较有用。。。2009/11/19 Shuo Chen <gian...@gmail.com>“国外公认非常有用”这个结论是怎么得出的？你知道哪些国外公司在用？它们用到什么程度？
为什么你觉得“大程序最好使用UML”呢？用了有什么好处？哪个大程序在用？
你的“UML有实用价值”这个印象是如何形成的？看书还是听老师讲？
郑培祥 wrote:
> 大家好，
> 和大家讨论一个问题，UML，国外公认非常有用，从形形色色的不断升级的工具（bouml
> ,rose,staruml)就可以看出，但是请问大家在实际工作中用到的多少呢？
> 我的理解：
> 大程序，需要保证的程序，最好使用，但是小程序，没有太多难度的程序，一般不需要使用，而中等程序，可以在关键部位使用一种工具（状态图，类图...)
> 我有几个问题不明白：
>
> 我发现公司很多不用的，不仅仅是小公司不用，一些中等公司也不使用，真是非常奇怪的事情，我是个学生，对公司的事情也不是很了解，这些事情是听说，或者不同单位实习的同学讨论得出的。
Shuo Chen
Cliff Peng
在纸上直接画图难道就不是使用 UML ？
Shuo Chen
发信人: easylinux (小熊：最大的困难是战胜自己), 信区: SoftEng
标 题: Re: uml工具心得（zz）
发信站: 水木社区 (Thu Aug 14 22:38:17 2008), 站内
你说的是UML工具的问题，我更关注UML这套建模语言自身的问题
某些书和“牛人”把UML忽悠得太厉害了，然后在实践中发现与宣传的差距很大，
这时候就有严重的失落感。所以有人戏称UML是Unwanted Modeling Language
在我印象中，UML以前几乎被宣传为万金油，可以用来做需求分析、业务建模、
概要设计、详细设计……甚至直接生成系统绝大部分代码，或者直接用UML定义出系统
的模型，绝大部分开发工作就完成了（MDA是干这个的么?）。总之，UML被宣传为好东
西，要多用。
可是我的实际使用经验告诉我：
1)从UML本身来讲，它定义了一套建模符号和语法规范，这些语法和规范在表示某些设计
理念/思想的时候很方便，比如OO中类的继承层次，或者系统框架/架构；表示另外一
些设计思想可能就不如其他方式合适甚至很蹩脚：比如嵌入式；又如设计编译器时，
借助lex/yacc，产生式就是最好设计；还有UI设计，画图工具绝对比UML有效；
在业务建模领域，UML也很稚嫩，很多东西用UML表达起来太费劲了。
就像不同的程序语言，适合不同的开发泛型或者开发领域。用delphi做MIS很方便，
JSP/JS比C++更适合做web，shell脚本适合做系统管理……
2)UML其实并不是精确定义的一套模型表示法，不同的人有不同的用法和使用习惯。这一
点 Martin Fowler在他的《UML Distilled》中说的很明白，这是一种很务实的态度。
这意味着，UML还是更多用在交流的层面，抽象概要的描述系统某个侧面；无法用UML
对整个系统进行详细、准确、无二义性的定义。指望从需求阶段画几张UML图、写点
UML文档，然后就平滑的推导UML详细设计、进而平滑推导出代码是不现实的。
很多东西，还是装在程序员脑海里，借助程序员的思维从需求跳跃到设计、再从设计
跳跃到代码，这中间绝对不是平滑推导的过程。
贬低一个人，会对这个人造成伤害；但如果把他捧到比实际更高的高度，也会造成伤害。
同样，一门技术也是如此。过分夸大它的作用，实际应用中必然造成落差，从而影响技术
的应用。
所以实际应用UML还是要扬长避短，用来画个系统框架、画几个类图还是蛮好的，很适合
交流使用；太详细太全面的UML图画起来会让人疯掉。如果UML用的爽，那就用；要是用的
不爽，那就不要勉强去用。貌似Martin Fowler也是这个态度。
===== 转载完 =====
最后两段是点睛之笔。
Fei Yan
其他的方面比较同意这位朋友的观点，他说的的确非常精确到位（我个人的感觉）；最后的总结也非常合乎UML的产业现实。
有一本很红的书，叫统一软件过程，就是将UML鼓吹成为万金油；
殊不知那么多形形色色的符号和含义、规则有多么难以实施；更别提它生成的代码有多么的蹩脚。
指望一个UML就能将软件活动变成机械化作业的方式目前看来是难以达到的；
更无须说UML最大的靠山OO本身在好多领域也越来越显其不足，其“万金油”的金身在日渐腐锈。
Shuo Chen
agree ，在喧嚣之后，先是对设计模式有了反思，接下来对面向对象这套方法论本身产生了怀疑。
工作了两年多，我重读 Robert Martin 的《敏捷软件开发》，比起05年那会儿，心境已大不一样。
我觉得，OO、DP、UML 是程序员的基本知识，不懂是说不过去的。不懂的话，与其他程序员交
流可能都会有困难（比如听不懂“Java里用Observer模式不小心就会导致内存泄露”），更可能面试
都通不过（常见问题：线程安全的 singleton 怎么写）。
所以这些都是要下功夫学的。关键是，学会了之后，要保持克制，不要随便到处用，不要觉得不
用就吃亏、白学了。用多了反而会吃大亏。
在 C++ 项目里禁用异常并不罕见，但是作为一名合格的 C++ 程序员，不能不知道异常处理的各
种关窍。（话说我觉得在 C++ 里乱抛异常就更随处大小便一样恶心。）
也可能一年也写不了一个类模板，但不能不知道 type traits 是怎么回事。需要的时候，随时能排
上用场。
Jeff Chen
--
My Blog：http://jeffchen.cn
Fei Yan
在它使用的场合，直接用就是了
不适用的地方，没必要一定顺着它的思路去找替代；那样可能得不偿失
能方便透露下你们是什么样的场景，生成的C++代码是怎样的效率高吗？
我们也有Ration的license，但是某几个项目用它生成的C代码都可耻的失败鸟，最后那个team的人白费了几个月时间的折腾之后决定重新设计并人工coding，结果成本反而来的低，因为好多UML自身的复杂性都消失了。
当时一个典型的失败场景（据同事口述）是，UML生成的代码有N多个状态机，每个状态机里边都自己启动一个block循环，结果多个模块integrated之后，变得基本无法控制。。。
jinhu wang
Jeff Chen
jinhu wang
简单点说就是设计模型于实现相统一了。生成的c＋＋代码属于中间代码，不用你去读也不用放到配制库的。
如果还要读和修改生成后的代码那就更像是mfc之类的工具了。