Re: [UML Forum] Guidelines for Coding From UML Diagrams

[H. S. Lahman]

Responding to rafael.soteldo...

I laud your desire to do the design in models and then produce code form them. However, there are problems with that...

All I want are guidelines that include best practices.

Best practices for what? Coding in a 3GL? The OOPLs make a lot of compromises with the hardware computational models (e.g., type systems) that tend to impede maintainable code. However, there are lots of books, like Fowler's Refactoring, that tell you how to refactor the code after creating a brute force transformation from UML to OOPL.

Are you looking for best practices for optimizing? If so, that is an enormously complex task because the level of abstraction of UML is much, much higher than that of the computing space. Back in the '70s it typically took 3GL compiler vendors 5-10 years to get good optimization for their compilers (modern shared back-end technology cuts that substantially). That task is vastly more complex for transformation from UML to OOPL. IOW, your brute force translation from UML is likely to run orders of magnitude slower than the same program written directly by a competent OOPL coder, so it will require a lot of refactoring to optimize it.

UML transformation engines that are well optimized often produce code that does not look much like the original UML model. For example, in a client/server application one might decide to use stateless objects on the server and pass state information as XML strings. Thus basic things like objects look quite different. There are many, many similar optimization issues. That's why designing transformation engines (i.e., applying good manual practices to automatino) is a even more highly specialized profession than 3GL compiler design.

I found a blog that had guidelines just for the main relationship types, like dependencies, n-ary associations, etc..

If you are going this route, KISS rules. Just because a feature is in UML, doesn't mean you have to use it. In the methodology I use, things like dependencies and n-ary relations are not part of the MDA profile. If you keep the UML simple, it will be much simpler and easier to do the transformation. (If you want a simple subset, check out my book or Mellor & Balcer's Executable UML.)

I something deeper.

Why? UML was originally based largely on Grady Booch's notation. As  George pointed out, that was sometimes called "Graphical C++" because the notation constructs mapped so closely to C++, down to kludges like "protected". If you stay away from exotic constructs, it should be rather simple to do a brute force transformation to most OOPLs. Then all you have to do is refactor it for optimization and maintainability. B-)

My point here is that, in practice, manual coding from UML designs does not work well. The big problem is the refactoring necessary for maintainability and optimization. The UML models essentially become throwaway because the 3GL code needs a lot of refactoring. That refactoring makes a mess when requirements change and the changes need to be incorporated in both the models and the code. You are much better off getting a commercial transformation engine. However, if you insist on manual coding, then there is really only one "best practice":

(1) Do the design in a simple subset of UML
(2) Transform the models to OOPL code as directly as possible.
(3) Throw away the UML models.
(4) Refactor the code from (2) using standard 3GL coding techniques.
(5) Reconsider using a commercial transformation engine.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Imagine how much more difficult physics would be if electrons had feelings
   -- Richard Feynman

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972