Java开发网 - Re:do we have visual-paradigm here ?:)

Java开发网

您没有登录

» Java开发网 » Design Pattern & UML

打印话题 寄给朋友 订阅主题

作者	do we have visual-paradigm here ?:)
littledeer1974 Garbage Collector CJSDN高级会员发贴: 1517 积分: 122	于 2005-01-11 16:10 http://www.visual-paradigm.com/vpumlScreenShots.php Surround yourself with people who are open to change

作者	Re:do we have visual-paradigm here ?:) [Re:littledeer1974]
linux_china 版主发贴: 752 积分: 240	于 2005-01-11 17:24 me, I am a sale man for this product. www.jetmaven.net, agent in Beijing.

作者

Re:do we have visual-paradigm here ?:) [Re:linux_china]

littledeer1974

Garbage Collector

CJSDN高级会员

发贴: 1517
积分: 122

于 2005-01-11 17:35

哈哈,把大象叫出来了今天查了查论坛,发现了UML的工具 visual-paradigm,其实以前也有所了解,现在想稍微正式的学习一下,不知道有什么好的建议没有,对了,还有就是,最近也看了不少大象的关于IDEA的贴子,我想我也得好好的对它在重新认识一下了,望回复
在把我想问的问题总结一下
1,现在什么样的UML工具(或环境)比较广泛的被使用
2.不同的IDE里边,一般都流行什么样的组合(ECLIPSE+**UML之类)
3.单独使用的话,有什么推荐
4.对于UML建模工具和提高开发效率的关系与现状应该怎样认识,尤其是现在国内的开发有多少,会回经过UML建模的部分,国外的朋友们也请大家谈谈(FLOATER兄啊谁的)
5.大家在开发工程中,想过要或希望使用UML建模吗?
(提问不专业的部分也请大家一并指出)

Surround yourself with people who are open to change

作者

Re:do we have visual-paradigm here ?:) [Re:littledeer1974]

linux_china

版主

发贴: 752
积分: 240

于 2005-01-11 18:44

惭愧啊！老实说，我在开发过程中很少用UML建模，一般会用Visio画一些流程图和结构图。我认识了不少开发人员大家对UML的认识大致分为这三类：
1 软件工程毕业的研究生乃至博士生，属于学院派人物的，实际编码工作比较少的，比较喜欢这些建模工具。
2 半途出家或本科毕业，一直从事程序员编码工作的，对UML觉得无所谓，主要原因是经验让他对项目有一定的把握。我就是 Smile

3 自欺欺人的人。碰到一个比我更有项目经验的人，编程语言，软件框架，IDE工具都比我厉害的人，我就用这些概念去和他谈，反正大家对这些都不是太了解，谁也没有使用过这些概念开发出很有名气的产品，不然被人看不起。我也是 Smile

现在流行什么，我不知道，我个人使用IntelliJ IDEA ＋ SDE(Visual paradigm产品)，其他的人应该是Eclipse+Together，使用以上组合的属于从编码过来的人员，Rose一般是学院派人物在用。现在又有MDA和DSL在捣乱，要懂的太多啦，现在正在忙着JetBrains推出的那个LOP的概念产品MPS。

最后说一下使用情况，从功能上将Rose > Together > VP-UML，价格也是一样，如果按照美金报价，一套Rose和Together绝对可以完成一套房子的首付。不过大家都用盗版，无所谓 Smile

，但是有一点，功能强的工具对你不一定适用，特别对那些Java开发人员，当然是够用简单灵巧即可。只选对的，不选贵的。婴儿穿大鞋，可能会影响你的速度。如果建模工具和IDE工具能整合，这是比较好的，不过现在建模工具好像都能和IDE工具整合，只不过这个IDE工具是否是你喜欢的工具。

关于工具选择。可能我用到是VP-UML，影响到我评论的客观，我也想使用Rose，挤进架构师队伍，能力有限， Smile

程序员的命。 VP-UML有一本E文书，现在正在看，不错的。而且网站有好多Flash教学，很容易上手。

以上完全从非专业观点分析专业问题，个人观点 Smile

作者

Re:do we have visual-paradigm here ?:) [Re:littledeer1974]

floater

Java Jedi

总版主

发贴: 3233
积分: 421

于 2005-01-11 23:54

Oh, my gosh, linux_china changed his career too, a salesman, Tounge

.

I am using WSAD + Rose at work, because that's the standard in the company. You can imagine what a nightmare it is. We just move into this in two months, so there are still a lot of integration issues, as usual.

I don't like to use standalone UML tools, like Rose. Standalone Rose even fixes the jdk we are using, this is ridiculus. I dropped right away several years ago. Now they have this IDE plugin, hopefully things get better. A round trip tool is better, like Borland tools, together and architecture. In general, I like borland stuff. There are some discussion here before, EA, VP, ArgoUML, etc. From my experience, they are better for newcomers and easier to learn. Once we pass the learn curve, it's more or less the same. After all UML is simpler than a computing language. However, there are some minor difference on UML restrictions among different tools. Even Visio UML templates do that too.

In here, Rose is used by many big, commercial companies, not just 学院派人物. Most of the cases I know are used in conjuction with RUP.

The most common problem with UML that I've seen is that folks simple draw the "wrong" UML charts. Syntactally, it's a valid UML chart, but semantically, it's meaningless. They draw the chart for the sake of the chart. When we draw UML charts, we want to express something, some ideas, some info. We shouldn't draw UML for everything, e.g., util packages(It's too much and confusing). On the other hand, we should document the "central pieces", like structure, states, etc(this saves us a lot of time later on for maintanence). I don't think there are a lot of materials out there that are talking about what we should or shouldn't draw.

I found UML charts are useful in:
1. troubleshooting: this is really handy for a quick scan on where the possible breaking points. The older the project is, the more help you could get.
2. communicate with others: it's easier to get to the points if your charts are right. Especially when you talk to your supervisor^3.
3. training: since UML is sketchy, so students won't even know to ask details, this saves you a lot of time for stupid questions.

当然是够用简单灵巧即可。只选对的，不选贵的。婴儿穿大鞋，可能会影响你的速度 - I agree, find shoes to fit, not stretch your feet to fit into shoes. Not only 会影响你的速度, you could fall too. That's why I argue with my wife about my daughter's shoes all the time, Tounge

.

Most of the 架构师s I've worked/talked with are really not that good because they lack of coding experience. A lot of coding issues have heavy impact on the designs and yet, quite some of them are hardly shown at the design level. In other words, this abstraction takes too much details away so that it's not a good/valid abstraction anymore. This is the major issue we are facing, or any good architect should consider and can't take light.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
- Martin Fowler, Refactoring - Improving the Design of Existing Code

已读帖子

新的帖子

被删除的帖子