So when I was at university I was educated on the benefits of UML and its future in code development.

But from my industry experience, I've found that while we do use diagrams—ranging from ER diagrams, class diagrams, state diagrams, to work flow diagrams—all of it is for communication purposes.

That is, I've never generated code automatically from diagrams, and from a communication standpoint, I generally try to keep my diagrams as simple and easy to understand as possible.

But when I look at Visio and Enterprise Architect, it seems they have many different types of graphs, shapes, properties objects, most of which I don't use.

Do people use UML to do more sophisicated things such as code or database generation?

  • 6
    @SK - We all know YOUR code is terrific and written in such a crystal clear manner that even a 5 year old can grasp the entire project by reading just a couple of your methods. However, for the rest of us who don't have your supernatural ability to write crystal clear code, diagrams are of tremendous benefit in describing how the system works in a succinct way and UML Diagrams are a standard way of drawing those diagrams. I am not claiming they are the best way, just a standard way that works for the most part.
    – Dunk
    Commented Dec 14, 2011 at 13:55
  • 3
    @Dunk, probably you've missed that moment when the rest of us invented a speech instead of a cave painting. Diagrams are almost always nothing but a way to obscure whatever they're supposed to represent. A plain text is always better. And the bigger your system, the more complex its behaviour, the bigger is this gap between a cavemen-era painting style of communication and a modern English. I've never seen a diagram I could understand without manually translating it into a text first.
    – SK-logic
    Commented Dec 14, 2011 at 14:11
  • 10
    @SK-logic - I thought a picture painted a thousand words? Commented Dec 14, 2011 at 14:53
  • 5
    @SK-logic: So there are some things better communicated through text. And believe it or not, others are better communicated through diagrams, and that includes system design, and not only OO design. And it may even be different for different people and no, your preference for textual information is not a god-given mark of superiority. Commented Dec 14, 2011 at 15:33
  • 3
    @Sk - while your opinion has some valid points, as a diagram alone almost never is enough and some text needs to be added. I'll just continue to make use of what you believe are useless diagrams while I continue to successfully build fairly huge systems with near impossible deadlines on sizeable teams because I haven't seen a better way to communicate to other developers yet. I know you have plenty of time to sit and individually guide every developer, but I'm too busy getting work done.
    – Dunk
    Commented Dec 21, 2011 at 21:42

11 Answers 11


Yes, UML CASE tools were one of the hot items of the 90s... and then failed to deliver.

The fundamental reason for this is that UML (or most any other kinds of) diagrams help to understand the problem and/or the program solving it only insofar the diagram is abstracting away the implementation details of the actual code. Thus (for any nontrivial piece of code), a diagram which is easy to understand is inherently useless for code generation, because it lacks the necessary details. And vice versa, a diagram which is directly usable for code generation doesn't help you much to understand the program any better than code itself. If you have ever seen a UML class diagram reverse engineered from production code, you probably know what I mean.

The only potential exception to this I know of is Entity-Relationship diagrams, which don't encompass code per se, only (as their name implies) pieces of data and their relationships. But I have never heard of a successful attempt to use any kind of UML diagrams for real code generation [Update] - i.e. more than class skeletons and trivial code like getters/setters -, except in special purpose tools/areas like ORM, as testified by Doc Brown below [/Update], and I think this is no accident.

I personally do not hate UML - I think that UML diagrams can be a great tool of communication - to show your intent and ideas during design discussions, or to visualize the architecture of your app. But it's best to keep them to this, and not try to use them for things they aren't good in.

  • 5
    Exactly. But then the question arises why UML with all of its pointlessly strict rules, and its consequently bloated tools to create UML, in the first place? Simple polygons and ellipses, connected by lines and arrows do just as good a job, if not a better one, at conveying intent as does UML.
    – Dexter
    Commented Dec 14, 2011 at 10:08
  • 1
    +1 for 90s hype, Hardware design was even moving in the opposite direction at the same time, away from schematic capture and towards HDLs.
    – jk.
    Commented Dec 14, 2011 at 11:46
  • 2
    From 1996 to 2002 I was working for a company where we successfully used UML diagrams as "better" ER models. We had our own code generators for generating C++ code for our ORM framework, SQL/DDL and documentation all from a single model.
    – Doc Brown
    Commented Dec 14, 2011 at 14:22
  • 2
    A great use of UML diagram is also scaffolding. Generate classes, with getters/setters, maybe your directory tree, etc. Commented Dec 14, 2011 at 14:32
  • 5
    @Dexter: the thing is that "Simple polygons and ellipses, connected by lines and arrows" leave lot open to interpretation. It may be that UML tries too hard to have a special symbol for everything, but there certainly is value in having a standardized notation that allows you to distinguish visually between classes and hardware systems, and between an inheritance relationship and a communication channel. Commented Dec 14, 2011 at 16:35

So when I was at uni (a while ago now), I was told that UML was the future, UML will replace programming and we'll just generate code from diagrams etc.

They were wrong. That will happen about the time people abandon speech and go back to cave painting.

Real-world problems, and the programs that solve them, have an essential complexity that cannot be reduced. To produce a working program, that complexity must be captured and expressed in some executable language. The question is whether some diagrammatic programming language could be more effective than a textual programming language. We have been experimenting with diagrammatic programming for about thirty years, and so far the evidence is overwhelmingly in favor of textual programming. I'm not aware of any important application that has been produced by code generation from diagrams.

  • 2
    +1, thank you for bringing up the issue about complexity of real word problems. Great point.
    – NoChance
    Commented Dec 14, 2011 at 8:21
  • what about G, the graphical programming language used in LabVIEW? Commented Apr 10, 2013 at 10:03
  • 1
    @Angelo.Hannes: Solving real world problems in labview invariable approaches looking like this: img.thedailywtf.com/images/201104/labview.jpg Commented Apr 10, 2013 at 16:11
  • @whatsisname this diagram is very cluttered. But I have seen very good structured and very "readable" diagrams in LabVIEW solving real world problems. Commented Apr 11, 2013 at 5:37
  • @Angelo.Hannes: I have used systems similar to LabVIEW. They are fine for building small applications in a limited domain. Commented Apr 11, 2013 at 14:40


The legend was based on the failed assumption that writing:

class ClassName extends SomeThing


...it's hard and needs automation.

You still may find the occasional believer, or crowds of believers.
But that's how it goes with religions and cults.

  • 4
    I really felt the need for an answer with a big NO somewhere.
    – ZJR
    Commented Dec 15, 2011 at 12:03
  • Well you can show easily 10 relations like this on a simple diagram but as long as source code is stored in files, worse one file per class it is much more difficult to memorize all the relationships.
    – Lothar
    Commented Mar 3, 2021 at 18:42

Been there, didn't find it too useful.

Generally the diagrams specific enough to generate some code from them, mainly class diagram, don't add much in the way of actually understanding the program and you can't generate code from the overview diagrams like use case or overview-level activity that are crucial for documentation. One diagram that is useful for understanding and can have code generated from is state chart, which comes in handy when you really need state machine. But generally you should try to avoid those, because they are inherently error prone.

On one project we were required to design the code in UML modeller (Rhapsody) and generate it from there. It kind of worked and was probably very slightly easier than typing the headers (it was C++) and prototypes by hand. The ability to keep those two consistent automatically was somewhat handy.

The method bodies still had to be filled in by hand, because the diagrams can't really represent that with exception of state machine skeletons.

On the other hand it is rather complex, so you have to learn a lot of extra stuff and more importantly it was pain to merge. Merging is well researched for text files and works with them, but nobody invented easy way to merge changes to diagrams yet. Rhapsody actually keeps part of the information in the generated code and parses it back, so it was not totally unusable, but it was still serious complication.

  • @mouviciel: I don't think there is a tool that wouldn't have such problems. Rhapsody actually tries to mitigate the worst problems by using the generated code, which is text, as authoritative for members.
    – Jan Hudec
    Commented Dec 14, 2011 at 11:02

While it's certainly possible to generate code (and even entire systems) straight from UML models, I've never encountered it being used in this way.

In my experience, most companies seem to use it as a communication tool for requirements, or "MS Paint for drawing diagrams".

One important distinction that I would like to make is that most UML modeling tools allow you to build up a single model of your system. Visio, for example, has a fairly good understanding of how UML works, and there are many things you can add that are not directly diagram-related. The actual diagrams are simply different perspectives on parts of the model, allowing you to highlight different aspects of the system.


all of it (modeling diagrams) is for communication purposes

Modeling has 4 important usages in the software development process:

  1. Integrated Design tool

  2. Communication tool

  3. An aid to software generation

  4. A way to reduce complexity of real-word problem (I learned this from @kevin cline's response above)

  5. The process of modeling gets some designers to think about details not considered while coding (and vice verse). Modeling at design time allows you to consider a bigger picture than coding a method or a class in a language.

Modeling in my opinion is vital for building databases (ER Diagrams), understanding process flows (Activity Diagrams) and understanding user-system interactions (Use Case diagrams).

Do people use UML to do more sophisicated things such as code or database generation?

Yes indeed. ERDs (not a UML diagram) and Class Diagrams can be used (depending on the capabilities of your tool) to generate:

1 - Data Definition Language (DDL)

2 - Stored Procedures for CRUD and Class Diagrams in your preferred language (less useful since ORM tools do more about this)

Amongst the most valuable features of modeling tools are:

1 - Ability to keep integrity of the model. If you do a change it propagates in the model

2 - Ability to answer where-used questions (where is the 'account' used in my model?)

3 - Ability to allow concurrent users to work on the model

4 - Search within graphical representations

5 - Printing control

6 - Layering (organize your diagram elements in layers) so that you can focus on a layer-at-a-time

7 - Database code generation for several database systems

8 - Model validation (checks consistency, missing keys, cycles, etc.)

So, modeling tools, specially the good ones, do much more than Paint.

  • 3
    I want to point out 2 things: 1. You like ordered lists.
    – talnicolas
    Commented Dec 14, 2011 at 7:19
  • @talnicolas, you are correct! I do:)
    – NoChance
    Commented Dec 14, 2011 at 8:18

We use Software Architect to do high-level designs and to document some of the more arcane component interactions in our stuff. We sometimes generate the skeleton of the app from the diagrams, but once that's done we maintain both separately, we don't try to reverse-engineer the code back into a diagram after it's complete. I used to use a tool called Rational XDE that worked pretty well for small programs, but it would get lost when you started adding in Swing event handlers or tried working with Struts.

I think a big part of the reason why people don't write in UML is that it takes a lot more work to completely specify everything in UML and then generate the code from your diagram. I know the US DoD is working with the OMG to develop some tools that will generate "proven" code from diagrams that have been verified correct, but my impression is that you will wind up with an order of magnitude more metadata than actual code. Which is probably good (it's documentation, after all), but generating metadata is no quicker than writing code, so you wind up spending proportionally more time.


UML itself is a notation system, so that it is of cause for communication and documenting. It is rare case to generate code from UML model, but yes there are guys doing it. Rhapsody users do it more often than Rose. The difficult part is to keep the model and code synchronized, for most of real projects, the cost is just too high.


In my latest project I am using UML-Lab(https://www.uml-lab.com). This is a nice tool which allows the model to be reverse engineered as well. The tool generates java code and even the JPA annotations which are fairly accurate.

The challenge to that is when working in a team. The model is static and is in a single resource which makes keeping it in sync with multiple developer changes a little difficult. There is trial version that is available for 1 month which is a good time to explore and compare with others if you are investigating.

This is the first time I seen a product doing Object modelling and data modelling in one shot along with code generation as well.

Otherwise in my past projects, I have always seen stale models which are inaccurate or either too detailed.

In my past projects I sometimes generated diagrams by reverse engineering. Most of the time I found the diagrams are cluttered and I preferred to draw them manually filtering all the noise.


I think we can use UML to generate code. Not business logic, as business logic is not a standard and varies application to application. Class diagrams along with ER diagrams can be used for generating interfaces, classes, hibernate entities, basic dao methods, etc. Other boilerplate code like facade implementation, data type converters(e.g entity to transfer objects)can also be generated with help of object digrams.

Also, as mentioned in previous comments, database schema, DDL scripts, etc. can be generated using models.

Using OAW, and modelling tool like Enterprise Architect, we can write stronger code generators, which can even help in generating configuration files, factory code using stereotypes and tagged values.

  • I have worked on projects with ~200 engineers using UML to generate business logic - mostly in the form of state machines, as well as deployment scripts from deployment diagrams. Almost all the answers here seem to assume 'UML' just means 'class diagrams'. Commented May 20, 2022 at 11:24

I still don't understand why the business intelligence with tools like Business Object is able to analyse and take advantages of all company information while at technological level we are still working at code level only or at abstract level with UML !!

The problem is not UML but model transformation between UML and MOF and code generation from a clas diagram or xmi using templates. UML is said to give an abstract view of the real world therefore you only see what is really important. Having said that how to generate accurate code if the UML diagram is just a view of the real world ? It is impossible and therefore model driven development which would generate code from a model has failed.

The solution is to transform to map the real world and therefore all project code to a single UML model. Having a single model and the project full logic you can then generate views from the model and not from the code each time. There is a courageous initiative made by Omondo within the Java / Jee technology. The concept is live synchronized MOF and UML directly with the code and ORM. UML diagram are now just a high level view of the model which is mapping the entire project. You can create hundred of views, add hundred of notes etc.... to have a better understanding of the project. The code will be generated only if the element is changed or created. Marvelous technology where the Java Id is mapped to the UML id without the traditional transformation bridge between MOF and UML. The Model is becoming a kind of project datawarehouse inside which you can navigate and take accurate decision.

What is also fantastic is to be able to model my domain at UML level and get my ORM annotations directly in the code and therefore using Hibernate I can create, erase, create my database, deploy etc... in a permanent continuous integration in which UML is piece of the all architecture and not the architecture itself of the project.

I have never been disappointed by UML as high level viewer if live syncrhonization with the code but was absolutely devastated by traditional using MDA with Model driven development templates code generation. Code generation from a model is like an HTML page coming from a word document. How to change it once it is generated ? It is just impossible to update and you spend more time to clean the code than to write from scratch !

  • 1
    That's not an answer man, just a complain. I agree a bit about why coders are still writting every single line code while it's EASY to create small code constructors with drag and drop. You're totally right about that Bussiness did a better implementation of the technology than the users who use it. You can create a whole pre-configured machine with your app in seconds, but u can't create software with few (thousands) clicks or key strokes. Extra. I've that Día and Pythonnect can do a nice work executing code right from your UML, but didn't test yet.
    – m3nda
    Commented Jul 1, 2016 at 1:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.