Learning UML diagrams and how to use them

I set out to "learn" uml late last year. It was one of those things that when you see someone create a uml diagram you think, hey cool, that looks really good. sets out what is going on in the class and the dependencies between each class etc. A fellow developer often use to draw some class diagrams and if you don't draw any uml diagrams they seem quite impressive and you have an opinion that the other developer is very professional. What you don't realise when UML diagrams are hazy dark art (you don't know them) is that they aren't really that difficult and they are basically just your notes and design doodles put into a standard format, especially the class diagrams. Uml diagrams to me are just way for everyone to doodle and design their code in the same way, so when you show you developer buddy he will understand what everything is.

I was also reading about design patterns at the time so I found that it helped me to learn uml because when explaining a design pattern a class diagram is a very useful visual aid.

It can be a bit overwhelming to start with because their are so many different diagrams but you probably won't need to learn all of them. What you can do is learn them well enough to read them so if anyone does show you a uml diagram you don't write or use yourself then at least you will be able to understand.

I basically only learnt the class, sequence and use case diagrams and really only learn those three because they were the ones I thought would be most useful. I would say that I do have a piece of software to draw these diagrams but I often find it easier and quicker to draw a diagram on paper, especially the first few drafts because you can quickly find that a design idea has a major flaw. I see it sometimes as similar to writing a unit test before you start programming because you design the class to do something and then you realise it has to do something else, this can then cause problems for your initial design. The most important result that comes out of doing a class diagram is that you have thought about the design and looked into the problem in a bit more depth. I find design idea slowly start to grow and then I do a quick class diagram and then slowly bits of it change.

The downside of not using some software to draw a uml diagram is that it isn't going to hang around after you have finished the project. It would be a useful aid to someone who then had to do some work on the project. Whether the diagram is quickly sketched or done using software depends often how big the project is and importantly how long I have got to do it.

class diagrams

I use class diagrams to try and work out the design of program and see what kind of dependencies the classes have. The main benefit of this I find is that by spending a bit of time roughly doing a class diagram then you can see the strengths and weaknesses of your design idea, which often completely different when written on paper. The visual aid of a class diagram is very useful, it offers a more holistic view of the code I am trying to write, it also makes it easy to explain to other developers what you are trying to do.

I often use Class diagrams as a rough plans jotted on a scrap piece of paper, I am never worried about sticking religiously to the class diagram because design evolves. The greatest benefit of drawing a Class diagram is the learning process you have done through to create it, all the ideas that didn't work help to fortify the idea that works, similar in many ways to writing some code, you learn about the nitty gritty of the problem and what parts are needed and what bits you can chop out.

Sequence diagrams

I like sequence diagrams to help show me the sequence (err yeah). If I have written some code for a customer then showing them a sequence diagrams is an easy way for them to understand how the program works from a user point of view but without having to explain any of the code.

Use case

I have to be honest I don't use these diagrams very often. Thinking about it now I would say it's probably because the work I do tends to be smaller scope and the customers want a web application so I don't really have to worry to much about gathering information about their processes and what information is being recorded here and there. Plus I don't really like them or find them that useful.


So what prompted me to blog about Uml diagrams. Well I have a found a good resource of information today about UML diagrams. I looked at the time and there are certain links to free UML resources but they tend to vary in quality. This link is fairly comprehensive but without going over the top, it's not a 30 page chapter on each diagram, it has enough information to quickly describe the major UML diagrams but not to bog you down. I think that when you are initially learning something, it's always good to have the end of the chapter in sight, especially if the subject is a bit confusing and hard going. Here is the link

http://www.agilemodeling.com/essays/umlDiagrams.htm

What I like about this resource most, is the layout and the fact he (Scott W. Ambler) has put a learning priority on each of the UML diagrams, so you can learn them in order of how likely they are to be used. So if like me you lose your enthusiasm you will have least learnt the more important/used diagrams. I think I am going to have a read of the medium priority uml diagrams just to get an idea what is involved and to see if they might be useful. Uml diagrams suffer from one of the classic learning difficulties. When you read them they seem easy and straight forward and the examples they use are easy to follow but then as soon as you get to using the technique on your code it call becomes very difficult. Some times there is only one cure to this, practise.