40

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?

RoboShop
  • 2,770
  • 6
  • 29
  • 38
  • 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
  • 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 Dec 14 '11 at 14:11
  • 10
    @SK-logic - I thought a picture painted a thousand words? – Michael Arnell Dec 14 '11 at 14:53
  • 1
    @Michael, yes, it does. Vaguely. With thousands of possible other interpretations. Good for art. Bad for an architecture. – SK-logic Dec 14 '11 at 14:58
  • @SK - To each his own. I choose to learn how a system or module works in 10 or 15 minutes of looking at pictures (if even that). You can dive into the code and take 6 months to years to understand how it all fits together. But if that is how you are more productive, I'm all for productivity. – Dunk Dec 14 '11 at 15:04
  • 1
    @Dunk, I would prefer to read a clean, plain English document, instead of looking at any code (no matter how clean it is). And, as for productivity: UML is only suitable for the object-oriented designs. And they tend to be overbloated, counterintuitive, and in general very harmful to productivity. I really doubt that you'll understand how, say, LLVM register scheduling works by looking at any kind of a diagram, but two paragraphs of plain English will be enough. You won't understand the Axiom type system this way, but it is cristal clear in English. And so on... – SK-logic Dec 14 '11 at 15:09
  • 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
  • 1
    @MichaelBorgwardt, may be, may be. But in the past 20 years or so I have not seen a single useful diagram describing a system design. I saw a lot of designs, some good, some awful, but one common thing was that all the diagrams was absulutely useless to everyone involved, not just me. So I guess that those claming that diagrams are useful had no other options, and there've been no other documentation besides UML. Probably that's the reason why it is so hard to find a single Open Source project which is using UML or any other form of diagrams as a documentation. – SK-logic Dec 14 '11 at 15:53
  • 1
    @SK-logic: Now that last statement is just ridiculously wrong. http://www.apachetutor.org/dev/request http://shiro.apache.org/architecture.html http://kernelbook.sourceforge.net/parportbook.pdf And let it suffice to say that if what you claim is true then your experience is not representative. – Michael Borgwardt Dec 14 '11 at 16:29
  • @Michael Borgwardt, thanks for the links, interesting. But even there, text is so much more important, and the diagrams can be removed without loosing any valuable information. I do not know if they can improve the readability and developers productivity (for me they're all greek), but clearly they're not essential to understanding. – SK-logic Dec 14 '11 at 16:37
  • 1
    We use Rational Software Architect do do our UML, and we're also required to put in class/method documentation. The only real value I found in generating Java code from the UML was to get stubs with documentation already in place. – Jordan Bentley Dec 14 '11 at 19:39
  • 1
    @SK-logic, *"So I guess that those claming that diagrams are useful had no other options"* - or maybe they are visual types, while you apparently are not? You see, [people have different learning styles](http://school.familyeducation.com/intelligence/teaching-methods/38519.html). – Péter Török Dec 15 '11 at 13:00
  • @Péter Török, I know the difference. The problem with UML is that even the most visually-inclined people I know could not read it properly. It just does not fit the purpose: too many details renders it unreadable, too little details makes diagrams useless, unless your architecture is excessively object-oriented (and in most cases, already broken due to this very fact). I am a visual learner myself, I always remember not just text contents but also how it looked like, where on a page which paragraph is located, etc. It does not help me with interpreting the diagrams. – SK-logic Dec 15 '11 at 14:04
  • @SK-logic: IMHO you are absolutely right about UML-diagrams. Wrong level of abstraction for systems design, and no strict semantics. But that does not mean graphical modeling is bad at all - only UML does not match the expectations. – Doc Brown Dec 16 '11 at 13:28
  • @Doc Brown, of course graphical models can be very useful, they'll work where text fails badly (e.g., electric circuits, Feynman diagrams, etc.). Math formulas are in between text and diagrams. Chemical formulas are purely diagrams. The problem with architecture is that no proper graphical language had been invented yet. Same for the visual programming - there is nothing useable besides a couple of very niche things like LabView. – SK-logic Dec 16 '11 at 13:32
  • @Sk-logic: "Flow design" is IMHO a promising approach (see link below in my comment to Peter Török's post). It has clear semantics and right level of abstraction. Problems I see is missing tool support, did not hit the main stream so far, and the same problems every graphical tool has to deal with when hitting a more text-oriented tool chain. – Doc Brown Dec 16 '11 at 13:43
  • 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
  • 1
    possible duplicate of [How important are UML diagrams for a successful project?](http://programmers.stackexchange.com/questions/144530/how-important-are-uml-diagrams-for-a-successful-project) – gnat Apr 10 '13 at 08:39

11 Answers11

70

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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
  • 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 Dec 14 '11 at 10:08
  • @Dexter, yes, I myself prefer hand drawn sketches on the whiteboard, which are usually disposable. Most of the UML tools are rigid and difficult to handle. – Péter Török Dec 14 '11 at 10:38
  • 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
  • 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 Dec 14 '11 at 14:22
  • 1
    Nowadays, the german software engineer Ralf Westphal has developed a modeling technique ("Flow Design") for an architectural approach named "Event Based Components" which can be easily supported by code generation from models (not UML models, of course). However, most of his articles are only available in german, here are some english resources: http://geekswithblogs.net/thearchitectsnapkin/Default.aspx, http://ebclang.codeplex.com/, http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx – Doc Brown Dec 14 '11 at 14:31
  • 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
  • They are also great for sarting a new project. You diagram for an overview, and generate the skeleton classes from that. DRY anyone? – Spencer Rathbun Dec 14 '11 at 14:40
  • @DocBrown, good point, it can indeed work on a special purpose area like ORM. I extended my answer above accordingly. – Péter Török Dec 14 '11 at 14:54
  • @DocBrown, about Flow Design I am not very fond of. My impression is that the guy is an electrical engineer at heart, who hasn't quite got what OOP is all about. One of the dev teams in our company is experimenting with FD, and to me the result looks overcomplicated, inflexible and clumsy. But this is just my 2 cents. – Péter Török Dec 14 '11 at 14:57
  • @ClementHerreman, that can be useful, although nowadays a decent IDE can do that for you too. – Péter Török Dec 14 '11 at 14:59
  • 1
    @Spencer: Modern languages and frameworks (e.g. RAILS) allow the source code to be perfectly DRY without a separate "code generation" phase. Repetitive code is a language smell. – kevin cline Dec 14 '11 at 14:59
  • @kevincline I don't know about you, but I'm lazy. If I start a new project, I have nothing but an idea. After I think about it for a while, I may have a diagram sketching out classes, some variables, stubs, and relationships. I don't want to then go in and type out everything that the diagram shows. Or did you mean that since this new, complex project layout is obvious in some modern language, I should have skipped diagramming entirely and just starting typing whatever popped into my head? – Spencer Rathbun Dec 14 '11 at 15:28
  • @Spencer: I'm lazy too. That's why I prefer typing to mousing. Do you have an application that can generate code from an image of a hand-written diagram? If not, then you still have to type the names of things, and their types and relationships. With modern languages and frameworks, once is enough. You don't have to write SQL to define tables, then repeat the column names as members of a class, then repeat them twice more to map the table to your class, etc. – kevin cline Dec 14 '11 at 15:54
  • @Dan Brown: that generation of "SQL/DDL" etc. is done by modern web frameworks from code in the target language. – kevin cline Dec 14 '11 at 15:58
  • 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
  • @kevincline Oh absolutely. If I hand draw it, there isn't any point in trying to do that. I'm thinking of using UML software, such as [dia](http://live.gnome.org/Dia) then running it through a converter. And I'm not thinking of trying to get all the details from the diagram. I don't care if it has all the variables, or "knows" that this variable is supposed to be private. Just broad structure info. – Spencer Rathbun Dec 14 '11 at 19:48
  • @Peter Török: Don't give a prejudice on Westphal's approach as long as you did not have a closer look at it. I tried FD and EBC by myself and had discussions with R. Westphal about his approach. It is not perfect, but IMHO much better than most other modeling/code generation approaches I have seen the last years. Event driven data flow modeling is exactly what I was missing in UML the last decade. And you will find the basic ideas of program design based on signal-processing components already in the famous SICP book of Abelson/Sussman. – Doc Brown Dec 14 '11 at 21:19
  • @Kevin Cline: yes, and not only by Web frameworks, we do this also for standard desktop applications, using the reflection mechanisms of C# or Java. But at the time I was talking about, we were using C++, without mechanisms like reflection. And our budget for a graphical CASE tool was much bigger than today ;-) – Doc Brown Dec 14 '11 at 21:25
37

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.

kevin cline
  • 33,608
  • 3
  • 71
  • 142
  • 2
    +1, thank you for bringing up the issue about complexity of real word problems. Great point. – NoChance Dec 14 '11 at 08:21
  • what about G, the graphical programming language used in LabVIEW? – Angelo.Hannes Apr 10 '13 at 10:03
  • 1
    @Angelo.Hannes: Solving real world problems in labview invariable approaches looking like this: http://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 05:37
  • @Angelo.Hannes: I have used systems similar to LabVIEW. They are fine for building small applications in a limited domain. – kevin cline Apr 11 '13 at 14:40
  • Database schemas are commonly designed and maintained via graphical tools. DDLs are declarative though, this might be what makes the difference. – JacquesB May 18 '15 at 13:25
  • It was as wrong as the later idea that patterns can replace the "senior" in senior developer. It's all about reducing the required salery of programmers. It had and still has barely any academic evidence behind. Now they try AI again and throw it behind every kind of programming problem. – Lothar Mar 03 '21 at 18:40
10

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.

Community
  • 1
ZJR
  • 6,301
  • 28
  • 36
  • 4
    I really felt the need for an answer with a big *NO* somewhere. – ZJR Dec 15 '11 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 Mar 03 '21 at 18:42
6

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.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • @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
3

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.

Daniel B
  • 6,184
  • 1
  • 22
  • 30
1

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.

NoChance
  • 12,412
  • 1
  • 22
  • 39
0

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.

TMN
  • 11,313
  • 1
  • 21
  • 31
0

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.

pinxue
  • 109
  • 1
-1

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.

koya
  • 1
-4

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.

Siddhesh Patil
  • 1
  • 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'. – Pete Kirkham May 20 '22 at 11:24
-5

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 !

UML_GURU
  • 258
  • 2
  • 3
  • 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 Jul 01 '16 at 01:10