As we do design & analysis before development, wouldn't be convenient to be able to generate Java classes from a class diagram?
This would promote more exhaustive design and better codes, right?
It's strange that why Google returns tons of tools to generate class diagram from Java classes but not the other way around.
No, it's much faster to write code than to draw diagrams on a computer. To generate a Java class from a diagram you would have to draw the diagram, and then type in most of the code anyway. Sure, you might not have to type get/set methods, but Lombok does a better job of solving that problem. For example, it's much easier to simply type "class X implements Y" than it is to draw a box, type "X", and then connect X to Y with the right kind of arrow. We have been experimenting with generating code from diagrams for decades now and except for a few very limited domains it hasn't been popular.
Also see this question.
I think the last few years have shown a preference for using class diagrams to document existing code as opposed to generating code.
Diagrams give the reader of the code a quick look at the overall structure of the systems in terms of its classes and relationships. Of course, the successful use of diagrams is dependent on the diagrams being kept in sync with the code; if they are not, then the diagrams are misleading. This is why you see tools to generate diagrams from code.
Generating code from diagrams feels so 1990s. It was popular in the Rational Rose days, but I don't see such tools being used so much anymore. I for one can code much faster by typing (and yes, by using code-assist) than I can by making a diagram. Even if you made a tool that made drawing class diagrams easy, would you expect most programmers to use it? A class diagram can only get you so far. You still have to write the code to implement the method bodies. And what kind of software checks your diagrams for consistency? What about importing classes from other packages? Who can remember all the symbols for public, private, protected, package-private? And how do we indicate static members with underlines in a convenient manner? If a variable is initialized to a complicated expression, how do we enter this? Even if it is entered, is there a compiler in the diagramming tool to check what we have?
And then, once the code is generated from the diagram, what are the chances that it is complete? Do we still have to tweak more of it by hand? If so, what if we find a mistake in the diagram? Do we lose our hand edits?
The whole idea of generating code from pictures or diagrams seems like a misguided attempt to make software engineering like mechanical, electrical, or chemical engineering. Or even architecture. In those fields, your "blueprints" are paper designs and your product is manufactured by using the drawings. Software is NOT like that. In software, the source code IS the blueprint/design, while the product is the binary made by the compiler.
Of course, there is nothing wrong with making class diagrams as rough sketches at a conceptual level, but if there was any value in generating code from them, I would think that we would all be doing this by now. (I know that last statement was not meant to be a deductive proof, but rather something that provides evidence for the claim, no?)
In some niche markets, where waterfall is king, class diagrams are required as part of the software design documentation.
In that case, generating code from diagrams makes sense.
We should know that what is being coded and where is it being written. So making an sketch before coding may be a good idea specially for beginners. It will let you be straight with your thoughts and can reduce the percentage of making errors. But if you are expert then there is no need for a diagram.
But if you are expert then there is no need for a diagram. - what about the people reading the code or coming back to the design to add another feature later?