what are the most significant disadvantages of using UML?

UML is a grea开发者_运维问答t language to model software for business requirements, but there is a growing community that points some disadvantages for some lacking features.

What are the most significant disadvantages that you find crucial for UML and what could it be a good alternative to solve this lacking features?

The biggest one is that it's yet another layer of red tape that gets in the way of just $#%$#% coding the thing and making it work.

The fact that people use it to "model software for business requirements", as you put it, and other such process-oriented claptrap. UML started out as a conventionalised way for programmers to communicate software to other programmers in a pictorial form. In that sense it's just formalised napkin-scribbling - and as such it is very effective. You can draw a UML class diagram on a whiteboard and I can understand it without quibbling over notation.

But somewhere along the line someone got the idea that a drawing notation could somehow be a process in it's own right, or at least a formal part of a larger process. And that's just silly. UML diagrams are a fine way to illustrate books, and quite useful as a means for engineers to scribble ideas back and forth. But that's where it should have ended.

I can say at least three:

1. It takes a lot of time to keep the diagram reasonable and synchronized with the actual code. UML diagrams don't run, but require a lot of time. So they are good only if your organization size can manage them
2. You cannot represent every condition in a sequence diagram. It's impossible if you want to deliver. So state diagrams should convey basic facts, not all the possible outcomes.
3. Good UML software costs money and it takes some time to master properly.

So, I think UML is good as a complementary documentation role, and only if the size of your organization allows it.

Solutions... well, in the end, diagramming is just a way to convey high level information to another person, in space or time (e.g. could be you in some year time). Extreme Programming shifts the burden of information retrieval from dead tree to living brain. Of course, it assumes that the living brain never forgets, and never quits. Extreme programming uses redundancy to reduce the impact of such occurrences. In a large company, a strong layoff round could wipeout entire teams, so storing information into brains can be risky. On the other hand, large companies have human power to waste, hence the diagramming.

Also, as WDuffy points out, if you are a designer, and you have to communicate to a team of programmers what they have to implement, it's much easier to use a UML diagram. Of course, a small company with a small team has generally small goals, and you can organize people with a different style. A small company UMLing will only produce UML diagrams of their revolutionary product, and then it will be bankrupt.

UML is not good nor bad. It can be a good tool, but it must be used in the proper context.

Lacking features?

well, I found that UML is strongly aimed at an Object Oriented vision of the world. Our company mainly developed in python, with a strong focus on module level routines. Objects were lightweight data containers, but all the logic was done at the module level. It's difficult to properly model this implementation style at the UML level, unless you resort to some "hacks" in the terminology. I guess it's difficult to model in UML for functional or procedural languages.

Another thing I find annoying is the assumption of use case modeling as a diagram. My experience is that the best way to convey a use case is to write a short story or a short code tingling the feature you want to convey. The story should be short, one page maximum. This approach has two advantages: if your story is a written prose, the Q/A team can read and test it easily. If your story is code, you can put it as a functional test and let it run during the night. A diagram does not satisfy any of these value added needs.

One issue with UML is due to its universality: things in UML cannot be always implemented directly in the target language, or some languages have capabilities that cannot be expressed in UML. So it can be better to know the implementation language beforehand, which restrain its universality.

See also the criticisms section on UML wikipedia page:

• Standards bloat

• Problems in learning and adopting

• Cumulative Impedance/Impedance Mismatching

• Dysfunctional interchange format

It's not Agile

What should have been the last word on UML was written by frustrated student "Candide Smith", well, really Eiffel author Bertrand Meyer.

Another disadvantage of UML is that it tends to overemphasize design, which can lead to 'analysis paralysis' (people over-analyze their problem) and feature creep (loosing sight of the actual problem). A UML design can only take you so far in solving a problem, and you have to be careful to jump into the code soon enough (but not sooner ;-).

UML is somewhat less applicable to the brave new world of loose typing and NoSQL databases. It has OO ideas of Class as a data structure rather than classification embed in it.

Another disadvantage, although not self-inflicted, is that it doesn't explicitly to facilitate abstraction. Everyone I know uses UML tools for more abstract modelling, but the way standards are written that is not obvious.

Another problem with UML (and big design up front in general) is that it's sometimes hard to anticipate all the nitty gritty implementation problems that you'll run into that may affect your design until you actually start implementing something. Granted, I'm a bioinformatics research programmer that works on small one-man projects, but I don't even believe in any design up front, at least for small projects. I believe in the following:

1. Make it work. (Just get a prototype up and running that has all the basic functionality, no matter how much it sucks. This forces you to see all the little nitty gritty details that might not come through in a formal analysis. Having an actual implementation of your idea makes it easier to see whether the idea was even really worth doing in the first place or whether it should be scrapped altogether.)

2. Make it right. (Only now, when you have a working prototype and you know that all the nitty gritty implementation problems are at least in principle solvable do you worry about good design. Refactor the heck out of it to follow good programming practices, reduce coupling, do proper error handling, yada yada yada.)

3. Make it fast. If it's application code, you'd better have proof that you've found the slow part. If it's generic library code, you'd better have good reason to believe that the piece of code could reasonably be the slow part in some use case for the library, i.e. don't optimize a function that noone would ever call in a loop.

For Class Diagrams in UML it only makes sense to use them if there is automated way to generate code directly from diagram. I have implemented such UML editor tool based on 4-tiers meta levels recommended by OMG (Object Management Group) and we had great success using UML in team of 5 devs over 2 years doing around 20-30 architectural iterations. The diagram was the root artifact of automated build chain making impact on hundreds of derived artifacts, APIs, generated Docs, DDLs, projects, tests etc.

So by itself UML in Class Diagrams part is great "programming" language if you actually do programming in it.

For Class Diagrams in UML if it is not translatable in automated way, then its fail.