锁定老帖子 主题:uml之实践感悟
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2010-04-27
楼主好像对你的老师很不服气啊呀,
我觉得人啊,还是应该学会回报,几年前,别人教你!你现在牛了,就说别人天真??? 其实,框架这个东西,你用 UML 画出来,也可以,直接以代码表现快速搭环境,也可以, 任何事都不是一成不变的,要看项目的紧迫度,我觉得, 一个很小的项目,又是很急,难道你还要用 UML画,一个一个地画,再产生代码?? 有必要吗 ? 像这种情况,框架师可以把代码大概写一下,让工程师有个整体的概念,有很多事,可以等项目后期再完善,以备将来维护, |
|
返回顶楼 | |
发表时间:2010-04-27
xiao-qiang163 写道 楼主好像对你的老师很不服气啊呀,
我觉得人啊,还是应该学会回报,几年前,别人教你!你现在牛了,就说别人天真??? 其实,框架这个东西,你用 UML 画出来,也可以,直接以代码表现快速搭环境,也可以, 任何事都不是一成不变的,要看项目的紧迫度,我觉得, 一个很小的项目,又是很急,难道你还要用 UML画,一个一个地画,再产生代码?? 有必要吗 ? 像这种情况,框架师可以把代码大概写一下,让工程师有个整体的概念,有很多事,可以等项目后期再完善,以备将来维护, 呵呵,说实话,我很佩服这位老师,uml的培训课程讲得非常不错,是我听过的培训里面讲得最棒的老师,另外,我是最近一个月才听他讲的课,然后有感而发,才写的这个帖子,写这个帖子的意思不是说我很牛,也并没有真正地说这个老师天真呵呵,只是有感而发,希望大家不要误会我的意思。 |
|
返回顶楼 | |
发表时间:2010-04-27
惭愧,都是画些简单的草图,估计连uml都不是,顶多是业务模型
|
|
返回顶楼 | |
发表时间:2010-04-27
UML用来描述思路是非常不错的。
但要做到相当的规范,是很困难的,是需要付出很高的代价的。 因此,我们使用UML要做一个权衡。在粗细粒度上做出选择。 |
|
返回顶楼 | |
发表时间:2010-04-27
不可否认uml确实是表述我们软件设计和需求分析的最好的预言了,呵呵,因此uml掌握的好的话,那么就能非常好地用他来描述我们软件的体系结构和基本思路,正所谓工欲善其事、必先利其器也就是这个意思吧,凡是把握个度就好。
真的有个时候想用个什么符号来表述一下某个意思,左想右想硬是找不到合适的来表述,但是了解uml的话,可能里面有很多符号可以非常合适地恰当地描述你的思想和意图。真是千里寻他千百度,原来它就在你手里,呵呵。 |
|
返回顶楼 | |
发表时间:2010-04-30
这个跟是否该画UML图,画到什么程度,画些什么图半毛钱关系也没有。
大量的翻工原因是软件工程本身没有被有序执行。需求没有搞定就已经开始编码了。上层的改动必然导致下层一层一层的变化。 UML是基于软件工程的,而中国的软件公司只有浮躁两个字,根本就没有严格执行软件工程的,所以你却照搬UML那套来用,翻跟斗是必然的。 |
|
返回顶楼 | |
发表时间:2011-01-26
UML,只是一种手段,一种交流的方式;楼主先前的做法太教条化了,自己也体验到了同步模型的痛苦。软件开发的最终目的是软件产品,其他都是为这个目的服务的。所以不管是各种模式、各种模型、各种开发方法,只可借鉴,不可死搬硬套,还是仔细分析自己项目的具体情况,借助这些方法论的东西,最主要是体会其中的思想,才能和项目完美的结合,不至于陷入僵局
|
|
返回顶楼 | |
发表时间:2011-01-30
UML是标准语言,但是具体的项目要具体分析,不一定每个项目都是需要这么标准严格。
项目总结时,将UML包含进来供后续的跟踪和更新也是不错的选择。 |
|
返回顶楼 | |