Unified Modeling Language

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.

And a picture usually says more than a thousand words..

This page was last updated on: 21 May 2017 .

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.