Friday, December 07, 2007

UML is useless (not to say sucks ;)?

Take a look at following UML class diagrams generated using Enterprise Architect:

Diagram I:

Diagram II:

I intentionally removed class names because they could disclose design patterns' names in question. But if you are medium intelligent monkey you can see that these diagrams are almost identical, nevertheless the first diagram represents State while second represents Strategy GoF design pattern.

Even if you are experienced developer who knows and uses design patterns everyday you probably don't see any difference in those diagrams, don't differentiate them and most probably don't understand them. But when you see the code everything will be clear and obvious and you'll know what's going on.

I'm asking here why should anybody use class diagrams? Maybe I generalize the problem but I really don't see any value in at UML's class diagrams. If I don't see the code I don't know the real dependencies, associations, implementations and so on, and so forth. More so when I look at class diagrams it makes the project obfuscated and unintelligible - I don't think that was the reason to invent and use class diagrams.

What are your experiences with UML?


leonardtbn said...

UML is the worst thing in IT world. It never gives me any clue.

Przemysław Bielicki said...

At my current job I see a lot of people looking at very complex UML diagrams and I see their faces. I know they are well educated and very intelligent engineers (I know them) but I see that they don't understand what they are looking at.

And some people claim that UML is here to help us :)

Anonymous said...

Imo, UML class diagrams are not completely useless; at least for a large project it lets you see the general relationship among classes etc.

but UML sequence diagrams just suck; waste of time

Przemysław Bielicki said...

OK - let's put it this way: any diagram that shows the "big picture" of the system is useful. Some class diagrams show nicely how some parts of the system work together but I only agree with you as far as "big picture" is concerned.

But anyway - you can draw the big picture without knowing UML - and this again proves that it is useless :)

Thanks for your comment.

Mathias Ricken said...

Code and UML class diagrams are not equivalent. There is a mapping from code to a UML diagram, this mapping is not one-to-one, meaning a UML diagram can represent more than one source code.

That doesn't make it useless. UML diagrams represent documentation that serves alongside the source code and the other comments. It doesn't try to supplant it.

And when you say that you don't have to use the UML convention to draw the "big picture", you are right. But then again, there is no real reason to use the GoF design pattern names, like "strategy" or "state". I could use other names, depending on the situation, and that description might make just as much sense, but the big advantage of using these terms that have become standard is that we share a common vocabulary.

I also disagree with the statement that UML sequence diagrams are a waste of time. I was once in a situation where I could have written a thousand words, and I still wouldn't have been able to crisply explain what the code does. A sequence diagram helped me out here.

Przemysław Bielicki said...

I agree with you that quite often simple diagram is worth more than thousand words - but you don't need UML for this. You can use you "Domain Specific Diagram" i.e. one that will be understandable for anyone even those who don't know UML. UML can help you but you can live without it.

Unknown said...

I highly disagree.

UML is not useless and it doesn't suck at all (well, maybe just a little, but - hey - why don't you come up with something better? "hey, dude just look at the friggin' code" is not enough).

UML class diagrams are very useful to understand dependencies between classes if you don't know dick about an application and you have to jump in on the spot with 2 feet.

Class diagrams don't probably add significant value in tiny-ass apps but if you've ever worked on big-ass architectures and apps you should know that without class + sequence diagrams you've no chance of getting up to speed quickly. And please don't say sequence diagrams are fine because using only sequence diagrams is like using DBs without relations (well, kinda).

I sincerely respect your opinion but - you know - I think you're talkin' bullshit.

Anonymous said...

If any of you script kiddies had ever worked on a real project you would know that UML Class diagrams can be used very effectively for Model Driven Code Generation.

Bitches don't know about my Software Factory.

leonardtbn said...

Any of you guys, who already deal with a big-ass project and loves UML, can show me how to make class diagram of Anonymous Inner Class of Java ?

I am curious how is Microsoft teams build their products. Do they use UML?

Anonymous said...

The post title was little misleading. In my opinion, UML is really makes the development work easier. And it is a great tool for documenting system architectures so the maintenance of the application will become much easier.

Anonymous said...

As any guy who has had mathematics in high school can tell you: your graph will only tell you anything if you use it well.

Axis, type of graph, which part of the data you plot, etc.

Same goes for diagrams - first choose what you want to tell - then choose the type of diagram - then only add relevant data. If it ends up not telling/helping the reader/viewer: you messed up.

That being said: class diagrams take such a small part in toolbox and it's really sad that there is such on uneven amount of time spend on them by teachers et al.

Anonymous said...

I rather use database diagram that class diagram, because with database diagram you can see all the dependencies just how they are.

Thiago Souza said...

UML is misunderstood. There is a direct understanding of some UML basic constructs, but most of them (as they are infinite) there ain't. So UML actually serves as a language framework so it's meaning is to be constructed inside a team. Without this, I agree, most engineers will be looking at it with a great interrogation mark in their faces.

Unknown said...
This comment has been removed by the author.
Unknown said...

When applied to an application domain, a class diagram is as useful as ER diagram is for a DB. It allows one to "see" the code of a domain.

On other hand it is a complete waste of time to describe a business logic using class diagram.

Anonymous said...

>> UML class diagrams are very useful to understand
>> dependencies between classes
>> if you don't know dick about an application
>> and you have to jump in on the spot with 2 feet

That is what the lazy powerpoint UML obsessed architects keep sayin.

You just need a smart developer and a good IDE like Eclipse or NetBeans.

Przemysław Bielicki said...

> You just need a smart developer and a good IDE like Eclipse or NetBeans.

Amen to that!

Anonymous said...

I think many people draw useless diagrams.

But that is largely a people issue, not a problem with the notation.

I'm not saying UML is perfect, far from it. But even if it were, I bet there would still be lots of people who just don't have a clue on how to use them to their advantage.

Do you think English is useless (not to say sucks) because there are so many lousy writers and bad spellers?

Like all notations, it takes some skill to use it properly. And deciding what to leave out is more important than deciding what to include.

Your example of strategy vs. state is misleading because they are in fact very alike, structurally. Whatever gave you the idea that a masked, high-level structural diagram of those two patterns SHOULD show their distinction?

As-is, those diagrams could just as easily have depicted a Drawing class that has some Figures with the usual Circle, Square etc. implementations.

A couple of well chosen sequence diagrams of some representative scenarios would show more of a difference between the two patterns.

In the end, after seeing the code everything will be clear indeed. But I'd rather have a look at a well-crafted set of diagrams for a few minutes to orient myself instead of chasing the control flow through source code for half an hour.

leonardtbn said...

I still remember the UML class in college. The professor said that soon, in the next 5 years, there is no need to write a code. UML reverse engineering will produce the codes for us.
Thats the dream that makes UML adopted everywhere!

Try to understand UML in the book of GoF-Design Patterns. It gives me nothing.

I can draw UML diagrams to pass SCEA. But I still prefer whiteboard drawing or explanation in writing literally.

Anonymous said...

I just read this post that actually proves, in the mathematical sense, that static reasoning about programs (which is similar, in some sense, to UML) is worth nothing.

I agree with that proof. I agree with your claim about UML. I don't see any value in it.

Anonymous said...

I hate UML. Its stupid and people that love it too much act like assholes.

Steven Noyes said...

OK, this is a rather old post but my thoughts.

UML is a problem looking for a solution. The problem is most people do not recognize that languages like:C/C++/Java/Objective C and such are actually design languages and not executable code. There is no need for an additional layer of abstraction to define the entire project.

There is a belief in academia that a pictorial representation is easier to understand than actual text but that was disproved 1,000's of years ago by the Babylonians. Software is, fundamentally, defining a process; processes are best described with words and not pictures. That is why we still do not understand cave paintings because we have missing context. Are they hopes or are they examples of what happened? Are they stories of events or allegories? We do much better with languages like ancient Egyptian.

So basically, UML is setting us back 1,000's of years in the software definition process because to get concrete enough to define a process, the notation becomes substantially more complex than simple languages like C++.

Anonymous said...

The problem with UML is that is tries to enter area where it should never enter. This should be quite simple methodology to explain using diagrams what software does. But at the same time it should be precise enough to avoid misunderstanding. Unfortunately UML turned out to be more philosophy. It tries to define many things but it is so chaotic that describing class function is practically not possible. Just take a look UML documentation (700 pages?) and find UML each symbol explanation. You cannot find? You are not alone.
Calling this 'language' is a comedy.
Some wise men usurps the right to create the software code from UML diagrams. This should never enter software level! Programming Languages changes frequently, each code can be optimized, needs precision, needs architecture fit...
UML could be very useful. But it became a religion with no potential to precisely define what should be done or how it works. Many home made diagrams are much better than 'official' UML.