UML Diagrams. When are they used?

Question

So ok I understand that UML diagrams help for the construction of a program, but when are they used? Are they needed before you start coding? do you need them so you know what you have to code? Or do you use them after you have coded the program?

Answer 1

Before, During and After.

You use them to describe requirements, intended architecture, software design, implementation and deployment.

Even operational procedures for using the software can be described in UML diagram form.

Answer 2

In my experience of using the methodology DSDM to drive the development of a mobile phone application, I utilised UML diagrams within the functional-prototyping stage(before the development began).

I found that they gave me a much clearer understanding of how the application should look, how it is interacted with amongst people and other systems and began to show me how the code should be structured.

For example, a class diagram would be created before you begin developing an application, as it allows you to think about what classes and attributes you might need.

Answer 3

UML diagrams are just a notation, so the real question is when should you use modeling as such. There are many different methodologies with different approaches and attitudes. Unified Process is one of them, which is free and greatly utilises UML, from it you can learn how can be UML diagrams used and how can they be useful. However, you have to decide which practices are good for you. I personally see UML and modeling as a tool which can be primarily used for code generation so those models are imho in fact declarative programs. However, they serve also well as documentation. On the other hand, it might be questionable if they are the best tool used for requirements and description of dynamic behaviour. I hope I gabe you some clues.

Answer 4

In my experience they are mostly used before implementation to communicate how a component will be built. They provide a way for people to review a potential design in a nice standardized format (desgin review). They can also give a high-level view of a system to non-developers who have interest in the system (feature review). I have also seen them used after implementation as a reference for new developers who need to learn how the system works.

Answer 5

I will take a somewhat different standpoint.

With the exception of Sequence Diagrams that are often in the architecture/design phases we don't use UML in its strict sense. I would say it is most useful in academia, when you describe something exact and theoretical.

In every day work, any boxes and arrows on a piece of paper will due. Actually a good rule to use is that if you can't explain your design on a single paper drawing it by hand, it is too complicated.

Answer 6

I've used them in a few different ways on different projects. I've seen class and sequence diagrams used as design-time artifacts that become part of design documents, and I think they can be very helpful at that time. They can help communicate the relationships between classes and how they they will interact. I find it helpful to at a glance, and know which what the interfaces & classes are, which ones extend/implement each other, especially when I'm attending a design review for someone else. I've found, though, that those UML diagrams can get outdated pretty quickly, if developers are not diligent about keeping their design docs up to date.

We use UML heavily on my current project, though, because we're using a UML code generation tool called AndroMDA. It definitely has its ups and downs, but we use it to generate some back-end classes, interfaces, stub impls, hibernate config files & spring config file. The hibernate & spring config files are possible because you add extra annotations to the UML. Anyway, because we're using this tool, anytime we make a change to the back-end code, we have to first start by updating our UML. So, it ensures that our UML is always representing what's really going on in our code.

Answer 7

I tend to be somewhat cynical on the subject... and answer that UML diagrams should never be used.

UML diagram tends to be used when you have to communicate whith people that does not really understand programming. The nice graphical drawings makes them more at ease and comfortable but usually as clueless as before.

In my experience UML is a big loss of time and tends to take the place of other tools both simpler and more efficient. Pseudo-code is as easy to read as a class diagram (easier, for me) and much easier to type ; use case is less efficient than a good User Story like in scrum or XP ; etc. All diagrams are a bother to maintain alongside code base and documentation. and you can as easily make design errors drawing them than otherwise (and as a bonus when put in UML form, design errors will become much harder to detect and overcome, agreed you probably avoid the most obvious ones when thinking about your drawing).

I believe I lost plenty of time drawing UML diagrams, but I'm still seeking for a case where they gave me any neat benefit.