Create UML diagrams after or before coding?

Question

I can clearly see the benefits of having UML diagrams showing your infrastructure of the application (class names, their members, how they communicate with each other etc).

I'm starting a new project right now and have already structured the database (with visual paradigm). I want to use some design patterns to guide me how to code the classes.

I wonder, should I code the classes first before I create UML diagram of it (maybe out of the code... seems possible) or should I first create UML diagram and then code (or generate code from the UML, seems possible that too).

What are you experiences telling you is the best way?

Answer 1

The important thing is that you think, before, during and after you code. If UML helps you do this, you should use it. Depending on the program you are writing, you might want to focus on algorithms, architecture or the user interface before you write the code.

Even before you start thinking about how you should write the program, you should also think about what you should program. Again, the kind of program you're writing dictates what exactly you should think about.

Answer 2

I always create them during development. This is a personal bias though.

Following iterative development for example means your code will evolve as the project progresses. Creating UML diagrams up front is therefore a waste of time, as after a while your end result will be nothing like the diagrams you started out with. Even with iterative development, things such as Test-Driven Development do not discourage UML diagrams. During the planning/design process for a story/task, UML diagrams can come in quite handy. However, that's not to say you should blindly write UML for every piece of code you write.

In contrast, UML diagrams allow you to express large ideas to other developers in a few simple images. From the diagrams other developers can grasp how the application/components are linked.

You're best off using UML diagrams as a tool, rather than a means in my opinion. Having industry experience I can assure you that just because books tell you to write UML/carry out extensive design before writing any code, it very rarely, if at all, works like that.

Answer 3

I think for documentation purposes UML diagrams are close to worthless since keeping them up to date is almost impossible. However I think that they are good tools before and at the starting stages of development for thinking over design and also reviewing it with other team members. So my answer would be a little bit before a little bit at the starting stages and not so much after that.

Answer 4

I do model ( when I do ) before coding, with pencil and paper, but I don't do 3 weeks of diagram or anything like that. Just, 1 day or every iteration start.

Spending time in a diagramming tool is among the most ridiculous way to lose valuable coding time ( IMHO ) .

Using pencil / paper and cellphone camera has proven useful in the past.

Answer 5

I'm not a professional, and have only used UML in limited capacity in my personal projects. My experience in trying to use UML strictly before coding tends to send my personal projects in to a pit of despair. I think this stems from trying to diagram ideas that don't yet exist or aren't properly explored.

They say "a picture is worth a thousand words". My interpretation of this is that you must have an idea in mind (or in words) before you draw a picture of it. An artist doesn't draw a picture of a sunset and then decide to draw a picture of a sunset. It's the other way around.

Diagrams are a documentation tool. Documentation is always past tense, meaning any documentation is about the decisions you've made in the past. In my experience I found it better to document my ideas in writing, and draw diagrams afterward. Like the artist, you need to decide what you're diagramming before you can diagram it. If you don't know what idea you're expressing, how do you draw a picture of it?

Use case diagrams for example, are a pictorial of your decision about what functionality a user should expect from your system. Class diagrams are a pictorial of your decision about the structure of your program's classes and their relationships to each other.

In the case of class diagrams, choosing nouns from requirements and making a diagram is ineffective. How do you know if those classes actually support the functionality needed to support the use cases? Studying the system, separating ideas into modules, writing down decisions about module interactions, and writing some initial classes (or at least their interfaces) solidifies your ideas. Documenting those ideas in a diagram simply makes it easier for people to quickly grasp the decisions you made.

If you make a database diagram, lets say for a purchasing system, you must make the decision that an order has many line items before you create a diagram showing that.

In effect what I'm trying to say is that I think diagrams are past tense like all documentation. You have an idea; you write it down and that is documentation. You have documentation; you draw a picture to make it easier to understand. I think it's better to create diagrams after you've analyzed the problem and created a mental and written model. Whether you incrementally add to the diagram after you make each decision, or build a complete diagram after you've made several decisions is up to you. Making diagrams for ideas before you have them, or before you understand them I think only leads to distress.

Answer 6

It is always good practice to have a design before you start. Whether that design is defined as UML diagrams or somewhere else does not matter. The question is what level of detail do you need ?

If in the environment you work in you need a design review before you start then you will need UML diagrams. They only need to be complete enough to convey what it is you are going to do.

Every place I have worked recently requires UML diagrams as a deliverable. What I do is create some basic ones up front and then modify them at the end, usually through reverse engineering the code.

Answer 7

what are you experiences telling you is the best way?

I'm modelling in UML and if it comes to Interfaces and classes and sequence diagramms it is more comfortable to use IDE and declare them and do a round-trip engineering and see all these methods and attributes appear in UML diagramms.

It's too tedious to declare everything in an UML tool.

Just my opinion.

Answer 8

The best is to let users do as they want. I mean if they want to model first the database and then model the application, you need to transform your database into code and then reverse your code into UML. If you want to model first and then generate code and database then you need to create diagrams and then use code generators. If you want to model and code at the same time with love code and model synchronization then you can use Hibernate tools to map your design to the database once the conception has been finished.

The usual UML cycle is to model and then generate code using MDD technologies. I prefer iterative approach but except Omondo UML the other tools prefer to use MDD and not short UML iteration cycles. I don't know why but ....

Answer 9

It also depends which programming / scripting language you use. As a long-time php developer I often ran into trouble to visualize existing code into UML. The most diagramming tools I know don't support the mixed datatype which is often use in PHP-Scripts. @see Is it possible to visualize a bunch of functions in UML

You wrote that you made the structure of your db in visual paradigm so I assume that you want to make the UML-diagrams in this program as well. With Visual Paradigm you can import source code and get an uml representation only if you use the paid version. In the free community version the feature is disabled. If you using the free version it doesn't matter if you draw the UML before, while or after coding. Most of the time, when starting a new project, everything is not clear, and while coding and testing the project, questions arise that were not considered when discussing the project. Often, however, there are also change / adaptation requests from the customer during development, so that the diagrams then have to be updated anyway. Therefore, I rarely use UML and when I do then usually while coding.

But as my predecessors wrote, everyone can do it as they want. UML is one of many ways to create a documentation. What should by no means be neglected should be inline comments. It should state who has coded it, what the code should do and which parameters and data type are expected. I have already had to debug a lot of code without this information and can say that it is a pain in the ass.