所在位置:答疑 - 内容   
十几年的UML最尴尬的也就在这里:大师们说得天花乱坠,实际的却一个都拿不出来
 

华南白种虎 (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下面有各种模型和代码示例,电梯、洗碗机、咖啡机、报警器...
"模型驱动开发"不是可不可能的问题,而是合不合算的问题。真实世界中,全面的"模型驱动开发"在嵌入式系统用得更多,因为有必要性(质量要求高),而且有可能性(类的个数少),而一个涉及上百个岗位的企业应用,既无必要性(对质量要求并不严苛),有无可能性(花不起那么多时间),往往会把建模用在刀刃上。