Is code commonly generated from UML? [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

NO

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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 !