floater
Java Jedi
总版主
发贴: 3233
积分: 421
|
于 2005-01-11 23:54
Oh, my gosh, linux_china changed his career too, a salesman, .
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, .
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
|