华南白种虎 (853**69) 2012-08-23 12:02:14
其实，十几年的UML最尴尬的也就在这里：大师们说得天花乱坠，实际的却一个都拿不出来
潘加宇 (3504847) 2012-08-23 12:20:04
哪些大师们说得"天花乱坠"？建模的那些专家都比较严谨，你找到哪一篇UML学术论文说到"天花乱坠"？
成功故事，你可以到Rational网站上去看看。现在UML工具差不多还有100种在更新，没有人买和用，那些厂商吃什么？
"大师说得天花乱坠""一个也拿不出来"是无知的人编造出来的谣言，先编造谣言，再攻击谣言，有意思吗？
说得天花乱坠是一些伪敏捷宣传，用来骗一些涉世未深的年轻人，让他们认为世界上有容易做的事情，有免费的午餐。
大家有这些功夫说这些，为何不静下心来，看看群共享里的资料，看看《软件方法》的第一章？你要批评一个东西，至少要先了解吧？
华南白种虎 (853**69) 2012-08-23 12:26:36
嗯，"至少要先了解"是非常正确的，我们也是需要一整套完整的资料去了解，好比说，从可行性分析、需求分析、概要设计、详细设计、编码、测试、部署、实施一个完整的过程，每一步UML都是怎样做的。
我们现在能看得到的，都是零星的，不完整的，非大型系统的，这才是问题的所在
华南白种虎 (853**69) 2012-08-23 12:30:26
我私下想，一个中型系统(50万行代码)，要画的图应该过千张吧
潘加宇 (3504847) 2012-08-23 12:57:10
建议你还是看看群共享里的资料和《软件方法》的第一章
潘加宇 (3504847) 2012-08-23 20:56:52
关于"完整的过程"：UML用在业务建模、需求、分析、设计工作流（工作流，不是阶段），这些年以来已经有不少书是围绕一个案例来讲解的，讲解工具操作连带模型下载的都有，其中不乏写得优秀的，可以自行用UML搜china-pub。从学习"完整过程"来说，如果认真阅读过其中一本，会有了解。也可以看我写的《软件方法》。
什么时候该出什么工件，这不是问题，问题在于工件的质量。
但真实的建模工作并非"完整过程"，而是由开发团队根据自己所做项目类型的特点挑着用的。
例如，一个工期比较紧迫的保险系统，业务建模和需求工作流就很重要，毕竟这个项目不满足甲方的需求，后面的生意也就没了，而分析设计就没那么重要，因为先不用考虑复用和扩展的问题，那么，团队很可能只在关键的业务流程做业务建模、关键的用例认真捕获需求，需要的UML元素可能只有：业务序列图、系统用例图、系统用例文档，然后按照熟悉的套路开发，甚至直接用存储过程来封装领域逻辑的都有。
反之，如果做一个心脏起搏器，这种类型的项目往往涉众较少，需求工作不难，难点在于这种系统对质量要求非常高，所以往往业务建模可以忽视，从系统用例出发，而且分析设计工作流才是重点，每一个类都要画状态机，并在状态机的级别调试清楚，保证不出任何问题，使用Rational Rhaspsody这样的工具，就可以从类图、状态图直接生成最后的C/C++代码，尽量减少人工编码引进的偶发错误。Rhapsody的Samples下面有各种模型和代码示例，电梯、洗碗机、咖啡机、报警器...
"模型驱动开发"不是可不可能的问题，而是合不合算的问题。真实世界中，全面的"模型驱动开发"在嵌入式系统用得更多，因为有必要性（质量要求高），而且有可能性（类的个数少），而一个涉及上百个岗位的企业应用，既无必要性（对质量要求并不严苛），有无可能性（花不起那么多时间），往往会把建模用在刀刃上。