|
锁定老帖子 主题：我们不需要UML了么？
精华帖 (12) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-04-11
gdpglc 写道 unsid 写道 "最后说一下Hashmap与Entity的问题该怎么处理，之前我也不知道怎么处理，后来上面的那位uml培训老师告诉我可以用uml 2.x中的组合结构图(Compostion Construction diagram)来表示复杂的类结构，例如java中的内部类和匿名类。
" 这点可能我孤陋寡闻，不过在设计时候，还有很多比Hashmap与Entity更细节的问题，可以通过扩充规范解决Hashmap与Entity的问题，但是UML规范始终是跟不上人们新的设计思路变化的。在实现代码的时候有很多精巧的设计，比如你把一个类设计成不可变类（类似String），你说这些算不算设计范畴？还真不能不算，你是通过充分分析这个类在并发环境下的风险。但是作为设计语言的UML更难触及这些问题，换言之你把UML给了一个实现人员，这个人员很难从中获得你要把这个类设计成不可变的信息。 所以我的观点是Hashmap与Entity，这种类型的问题他们是不可能用在UML中的，一个系统的设计UML仅仅代表了最最基础的一部分，是蓝图，有了UML你仍然什么都做不了。 个人觉得软件开发是一个复杂的过程，从最初的对用户需求的调研到最终的功能落实为代码，UML要做的是建模，而不是什么都管。在整个软件开发过程中都可以使用UML，它不只限于用来做设计的。 我不认为UML是一个万能的符号语言，用来记录软件设计中的细节，如果这样，做多少它都不够。细节完全可以用自然语言或者代码来表达，而隐藏在代码和细节背后的模型，才需要UML。 你举的例子其实和我下边的问题的实质是一样的： 为什么UML画完之后是不可执行的呢？ 对于设计来说：UML是用来表达软件背后的思想的，是用来表达软件的骨架的，画UML图最忌讳的就是大而全的图 。如果UML能用来刻画软件执行的每一个细节，又何需代码人员将它转化为代码？ 你说这些，好象你认为开发是：设计人员用uml事先把什么都定好，然后给开发人员开发的。在这一样个开发过程里，首先不是UML对不对的事，我想首先是这样行不行得通的问题？难到设计人员什么都要替开发人员事先把怎么做想好？就算这样行， 这种分工，面对的主要挑战将是交流，而你把交流的责任全部推给UML，把交流的问题怪在UML上，有点偏激吧！ 我觉得你的说法很有道理，我也这么想过，我只是很想从别人嘴里也听到这些东西。 我觉得基本可以认定这点“只要设计做的好，过程做的好，最终装配（实现者）的能力不重要”这点在制造业适用在软件行业不适用，按照你的说法，“不可变类”应该属于实现者该思考的问题，如果不做这样设计可能会对系统造成很大损伤，所以实现者能力依然决定项目是否成功,尽管设计的到位依然存在失败的风险，在软件开发团队中每一个人都很重要，这也是为什么软件业的优秀团队比其他行业更难组建的原因。 |
| 返回顶楼 | |
|
发表时间：2010-04-11
敏捷的核心理念之一就是： Adapting （适应）。
根据实际需要来决定UML是否对自己的项目有帮助。不过我个人感觉有时UML还是非常有用的。 |
| 返回顶楼 | |
|
发表时间：2010-04-11
最后修改：2010-04-11
if eles if else for while
画结构化的流程图大家应该都见过了。 相信大家也都应该画的不错 面向对象。。。。。 这利器一出。。。。。 再让你画个结构化流程图 根本没有用。。。。。。。 之后就有了UML 但用的人太少了 我学会之后全还大学老师了。。。。 |
| 返回顶楼 | |
|
发表时间：2010-04-11
讨论到这个程度，我觉得不那么纠结了。
关于开源项目为什么找不到UML图的问题我不认为是上面某位朋友说的“apache有选择地发布文档，便于管理”，我觉得他们就是压根不画，他们是哪种喜欢用高质量代码直接说明问题的人。 |
| 返回顶楼 | |
|
发表时间：2010-04-12
其实从OO来说，数据库表字段跟类中属性基本能对应。
所以维护数据库表结构关系，有个数据库表结构关系图看看就很明晰了。 pd12用的比较多，基本就是看表机构关系 不过还有个borland的architecture together这个用来生成数据库表结构文档，效果更好 |
| 返回顶楼 | |
|
发表时间：2010-04-12
其实这个问题换个问法就清楚了。
我们不需要建模了吗？ 显然建模是需要的，即然如此，UML就是一个不错的选择。 |
| 返回顶楼 | |
|
发表时间：2010-04-12
gdpglc 写道 其实这个问题换个问法就清楚了。
我们不需要建模了吗？ 显然建模是需要的，即然如此，UML就是一个不错的选择。 我明显不是想说的这个，谁都知道需要建模，我是在质疑uml对建模有多大贡献，其实写的好地代码自己就给自己建模。 |
| 返回顶楼 | |
|
发表时间：2010-04-12
unsid 写道 gdpglc 写道 其实这个问题换个问法就清楚了。
我们不需要建模了吗？ 显然建模是需要的，即然如此，UML就是一个不错的选择。 我明显不是想说的这个，谁都知道需要建模，我是在质疑uml对建模有多大贡献，其实写的好地代码自己就给自己建模。 你可能是想说，用代码进行建模行不行？ 你要知道，需求调研、分析、设计、这时都是不会写代码的。代码并不是建模语言。 |
| 返回顶楼 | |
|
发表时间：2010-04-12
很多开源软件开发参考文档仍然都是收费的，不公开uml，序列图更大可能是这个价值更高
写到大几千行代码，靠脑子已经很难维护代码，多好的代码都一样。越好的代码越颗粒化，以平均40行一个函数，1w行原始代码就会达到近250个函数，撇掉属性，到了十几w行谁还能光拿代码说话，造火箭的难道能牛逼到拿电路说话 |
| 返回顶楼 | |
|
发表时间：2010-04-12
ppgunjack 写道 很多开源软件开发参考文档仍然都是收费的，不公开uml，序列图更大可能是这个价值更高
写到大几千行代码，靠脑子已经很难维护代码，多好的代码都一样。越好的代码越颗粒化，以平均40行一个函数，1w行原始代码就会达到近250个函数，撇掉属性，到了十几w行谁还能光拿代码说话，造火箭的难道能牛逼到拿电路说话 赞同。 光看代码我们很难一下子看出类之间的关系，采用的模式。 数据库er图能看出实体关系，1对多，多对多之类，uml里的类图比er图稍微全面一些。 状态图，序列图，对理解设计意图帮助很大的。 |
| 返回顶楼 | |
