Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 Dec 14 '11 at 13:55
1  
@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 Dec 14 '11 at 14:11
7  
@SK-logic - I thought a picture painted a thousand words? –  Michael Arnell Dec 14 '11 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. –  Michael Borgwardt Dec 14 '11 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 Dec 21 '11 at 21:42
show 13 more comments

10 Answers

up vote 50 down vote accepted

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.

share|improve this answer
4  
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 Dec 14 '11 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. Dec 14 '11 at 11:46
1  
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 Dec 14 '11 at 14:22
2  
A great use of UML diagram is also scaffolding. Generate classes, with getters/setters, maybe your directory tree, etc. –  Clement Herreman Dec 14 '11 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. –  Michael Borgwardt Dec 14 '11 at 16:35
show 13 more comments

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.

share|improve this answer
2  
+1, thank you for bringing up the issue about complexity of real word problems. Great point. –  Emmad Kareem Dec 14 '11 at 8:21
1  
+1 for cave paintings –  Izkata Dec 14 '11 at 19:23
    
what about G, the graphical programming language used in LabVIEW? –  Angelo.Hannes Apr 10 '13 at 10:03
    
@Angelo.Hannes: Solving real world problems in labview invariable approaches looking like this: img.thedailywtf.com/images/201104/labview.jpg –  whatsisname Apr 10 '13 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. –  Angelo.Hannes Apr 11 '13 at 5:37
show 1 more comment

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.

share|improve this answer
3  
I really felt the need for an answer with a big NO somewhere. –  ZJR Dec 15 '11 at 12:03
add comment

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.

share|improve this answer
1  
+1 for mentioning the merging issue with Rhapsody. –  mouviciel Dec 14 '11 at 10:27
    
@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 Dec 14 '11 at 11:02
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
1  
I want to point out 2 things: 1. You like ordered lists. –  talnicolas Dec 14 '11 at 7:19
    
@talnicolas, you are correct! I do:) –  Emmad Kareem Dec 14 '11 at 8:18
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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 !

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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