UML is a so called modeling language which can be used to visualize constructs
and/or ideas used within Object Oriented ("OO") programming.
This basically means so much as the ability to model and display all stages
of your program using one of the thirteen available diagram types.
Why design when you can code?
When I first came into contact with 'charted software design', or software
flowcharting or whatever it was called back then (we're talking the 90's)
I just couldn't understand the use. After all: all the time spend on trying to
make some vague diagram could be better spend on coding. And if you need
to know what a program does then simply go over the source code to get
you back up to speed. Easy, right?
Well, I sort of came around from that idea. Although I also think that
the modelling tools and standards which we had to learn back then were completely
uncomparable to the flexibility and ease of use which UML provides today.
But sure; going over your sourcecode will tell you a lot. But if you haven't
touched your source code for a longer period of time then it can become quite rough to
get with the program again so to speak. And another thing: going over a (rough)
description most likely takes much less time than trying to figure out every
aspect of all your routines again.
And that example isn't even touching the optional relationships between
code segments ("classes"). Something which is very common when
programming while following an OO model. But most of all: what about other people?
When you're trying to go over someone elses code then chances are high that their
coding style doesn't always match yours. And that can make it more difficult to
get a good overview of what their software needs to do.
So sometimes investing a little time can save a whole lot more in the longer
run.
But why design while you can code?
Simple: to make sure you're setting up your program as efficiently as possible.
And also to make sure that you're prepared for the future. And it's that last
part which more than often goes wrong the very moment a software project slowly
starts to become a lot bigger than people anticipated at first.
For example; what do these projects have in common:
Even the Linux kernel itself perfectly
fits in this list.
Answer: At one time in history all of these projects have been either partially
or completely rewritten from the ground up. In most cases to solve lots of
problems which crept in over the years and eventually could not be (easily)
solved but to start rewriting. That is: rewriting and redesigning.
Sure, I know some of these projects have become huge over time. And I'm
also not trying to suggest that those problems wouldn't have happened if the
developers had been using UML. But I do believe that some of the problems
could have been avoided with a little more planning and designing. Although
you can't anticipate for everything to come, you can prepare for a lot
of it. And that's where UML can definitely help out.