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?
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?
22 comments:
UML is the worst thing in IT world. It never gives me any clue.
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 :)
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
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.
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.
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.
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.
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.
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?
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.
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.
I rather use database diagram that class diagram, because with database diagram you can see all the dependencies just how they are.
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.
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.
>> 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.
> You just need a smart developer and a good IDE like Eclipse or NetBeans.
Amen to that!
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.
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.
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.
I hate UML. Its stupid and people that love it too much act like assholes.
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++.
Post a Comment