ten reasons i hate uml .txt

一些关于UML的经典讨论

Ten reasons I hate UML 

--------------------------------------------------------------------------------

转载一篇小文，供大家参考。作者的观点虽然有些偏激，但他的某些意见值得所有正在学习和使用UML的人借鉴。在“打倒”这个人的观点的同时，也许能真正了解和体会UML的意义。 

Ten reasons I hate UML 
I have tried searching the web for criticism of UML, and UML CASE tools – 
and there is surprisingly little. So am I wrong to harbor criticism of UML, 
or is this a case of the emperor’s new clothes? 

1. 
C++ added OO to C, but we had to wait for Java for a clean break to a 
simpler, cleaner, more productive language which many programmers are glad 
of. What’s the point of a producing designs for a new programming language 
using an old modeling language? For example, Java cleaned up the 
by-reference, by-pointer or by-value complication to a single by-reference 
standard. So why should the modeling language allow more than one type of 
association (association, aggregation and composition) – either the modeling 
language is wrong or the programming language is wrong. Either the 
distinction is important or it is not. 

2. 
If you let the programming language also be the modeling language, then the 
CASE tool can look deeper into the model, and be smarter, and save the 
modeler more work. For example, in UML, classes are allowed to have multiple 
super classes. But for Java modeling, what is more help is a tool which is 
smart in dealing with interfaces and single inheritance of classes, or that 
an interface cannot be derived from a class, or that a final class cannot 
have subclasses. UML CASE tools can never achieve this, because they don’t 
know the target language for generation, so they have to blindly allow any 
inheritance graph. 

3. 
If the modeling language and the programming language are one and the same, 
then you don’t need a model file – source code is all you need to store the 
model. When you lose the model file, you lose all sorts of problems which 
hold up the use of CASE tools by the world’s programmers. 
- impedance mismatch between UML model and the implementation, 
- reluctance to move into implementation in case the design is not mature 
enough yet, 
- holding up the development team when you go back into modeling, because 
model files are not that easily shared compared with source code files, 
- lock-in to a proprietary format for model storage. 

4. 
If the diagrams notation is intended for hand drawing (as is UML), then a 
CASE tool cannot take full advantage of computerized editing and browsing, 
which includes expanding and collapsing of information, tooltips, 
navigation, color, filtering and ordering. Computerized models should be 
alive and accessible, allowing you to highlight and focus as you browse, not 
be frozen snap-shot representations. Real-world software projects are 
complex, dirty and cluttered; so surely you need a tool which lets you 
filter what you look at as you look at it. All the examples in UML 
documentation are clean, simple and neatly laid out. 

5. 
UML draws on other engineering disciplines for examples which back up the 
need for design and method. Sure, an architect has to design a building 
fully before construction starts. Without a design up-front, materials would 
be wasted as ideas are tried out, or the bottom of the building may end up 
not strong enough to support the top. Software development enjoys much more 
flexibility, allowing prototyping and restructuring (within reason). 
Architects use virtual reality models to gain the try-and-see-at-little-cost 
freedom – so why would software engineering want to be tied down inflexible 
methods. Do a design – yes – but there shouldn’t be a penalty for returning 
to design if you realize a mistake has been made, or new requirements have 
come along. 

6. 
Architects produce drawings and models showing how, for example, a shopping 
center, which is in design, may be used – a few cars in the car park, people 
browsing the shops, chatting in common areas. But this is obviously not the 
specification for the builders to follow. So why does UML mix their 
equivalents (collaboration, sequence, object, use-case) with the hard 
specifications (class diagrams) all in the same model, (and pretend they can 
all take part in the round trip). Some diagrams convey expected usage 
patterns only, but OO components should be ready for reuse, not tied to a 
particular context. 

7. 
Sequence diagrams show the dynamics but: 
- Don’t you blow the encapsulation by digging deeper into the internal 
workings? It is fine to use sequence diagrams to understand an existing 
system, but is a confusing way to create an OO design where separation of 
WHAT from HOW is the key. 
- Isn’t it easier just to write the code than go to all the trouble of 
creating sequence diagrams. 
- In the reverse direction, helpful as sequence diagrams are, isn’t it 
quicker to step through the code with a debugger (again – an example of the 
advantage of a computerized view over a static pictorial view). 

8. 
Isn’t UML just plain awkward in some respects: 
- types and identifiers switched order to Java (and C++ and C) 
- lists of parameters in a straight line, never wrapped 
- association lines don’t link up with the data members which effect the 
association 
- Java constructs not visible on class diagrams; it is important to see at a 
glance which methods are synchronized, which methods throw what exceptions, 
which data members are final etc. 
- and as for inner classes… enough said. 

9. 
Standards are important but if you let the programming language be the 
definition then that’s a solid enough base (alright, so Java is still 
expanding, but the core language is fairly settled now). 

10. 
Why does the view format have to be frozen for everyone. Why don’t you 
configure your view of the model so you can see what you need to see, in the 
same way as you order and filter information as you browse a database? UML 
dictates the way it looks.