UML for mainstream developers

I’d like to explore the idea that UML could be made more useful to mainstream developers if it were redesigned so that a UML model could directly represent the semantics and terminology of modern programming languages.  For example, if you are working in C#, instead of having Attributes and Operations in your class diagram, you would be offered Fields, Properties, Methods and Events.  Instead of Features you would see Members.  You’d be able to see direct representations of delegates, lambda expressions, constants, variables, and blocks.  Instead of Packages you would see Namespaces and, separately, Assemblies.  All of this would be fully integrated across structural (class, package, component) and behavioural (sequence, activity, state) diagrams.  In a heterogeneous world you’d be able to define models of your systems at a large scale independently of implementation technology, and be able to drill into the detail of particular technologies for different elements of your system.   There would be diagrammatic counterparts for scripting languages and web development technologies.

What do you think?  Tell me your experiences.

Comments (12)

  1. Arnon Rotem-Gal-Oz says:

    I think that if you have a model which is on the same level of the code it is just wasteful – code has richer semantics on the one hand and the abstraction is not high enough to really simplify the view on the other hand

  2. Pedro J. Molina says:

    Hi Steve:

    IHMO that is not the intented usage I expect from UML. I preffer a a tecnologic agnostic UML. First tools implementing UML (like Rational Rose and many others) tried to to it mapping the direct primitives types for attributes directly to implementation types.

    On the other hand, when drilling down to code and algorithmics, textual languages are more scalable than a graphical notations.

    Probably, I am not seeing property your case of use, mine is Conceptual Modeling.


    Pedro J.

  3. Anil says:

    UML can be used to specify, visualize and document systems that are written using any OO language….so as long as your modern programming languages are OO based, there is no reason why you should not be able to use UML…

    when it comes to forward engineering …ie converting a uml model into code…. you have to use MDA tools… andromeda … for which you could write catridges for a specific language … that will convert the model into actual code….

    so expecting just UML to give the exact language semantics is not something that it is meant to do…. you need UML + for that to happen…

  4. What about reverse engineering and visualization scenarios?  Do you think it is valuable to be able to show a body of existing code in diagrams?  If so, do you want those diagrams to be technology agnostic?

  5. Anil says:

    Hi Steve,

    I think there is value in showing a body of existing code in diagrams… doubt… but the idea behind MDA (note that i am not saying this works perfectly well and has no issues)  is to ensure that you model (in a UML representation) never gets out of sync with the actual code and vice versa….and it expects us developers to be diligent enough to always change/update the model first and then forward engineer (without losing the actual code that developers write of course) … which means that according to MDA…we should never have just code …without the model in the first place…

    but as it is well known…we do have lots and lots of code with no model….or the model represents a sub-species or a different species of what the actual code depicts….so in such cases, not sure what MDA advocates….but if money is not an issues, something like Rational Rose, will definitely be able to reverse engineer and give us the uml models from the code base…

    I do think there models to be technologically agnostic is the right approach / way …. because, there are at a higher level of design understanding….and by introducing various constraints of a language, we should be able to code the app in different languages…. i.e we might still be able to get to a decent level of design, then once the language is locked down….we get to convert that into actual code….



  6. Erik Engbrecht says:


    I don't think UML works with any OO language. First, most languages are multiparadigm, which immediately creates a mismatch with UML.  If functional (not procedural, functional) constructs are critical to your design then UML is really an obfuscation tool.  Also, scripting languages like Python and Ruby offer metaprogramming capabilities that are used extensively.  Again, while the languages may be OO-dominant, there are critical features within them that simply don't mesh with UML in a clean way.


    I think it is valuable to be able to show an existing body of code on diagrams…but there were tons of tools to generate diagrams (although not necessarily UML) from code already.  If you're going to morph UML to match the language structure and semantics anyway, why even bother with UML?  Just generate diagrams that match the language structure and semantics.  Likewise for forward engineering (although the tools don't already exist).  If the graphical notation is going to align with the implementation language, so the notation is no longer standard, what's the point in trying to jam that into UML?  It seems like just begging for excess complexity.

  7. Anil says:

    Hi Erik,

    I agree with your point on UML not working for languages that have a functional / procedural facet along with OO principles.

    I was curious about the tools that generate non UML diagrams from code….. it would be very helpful if you could give out some pointers on such tools…. sounds like very good option to have …



  8. Andras says:

    As mentioned before, universal graphical notations do not scale well. This will be the same for any general purpose modeling/description language.

    What we need is powerful domain specific languages which cover specific aspects and are not intended to describe the whole world. Of course, having graphical counterparts of these languages is very useful too. The diagrams are useful to get an overview of "more than one page of code" in any language. While the textual editing can be a lot faster, in most cases.

    Reverse engineering is sometimes effective. But mostly only for getting the overview. However, creating the 1-1 mapping for general programming languages (GPL) is practically impossible without sacrificing the good information compression of graphical languages (GPLs allow very different expression of the same things).



  9. XXX says:

    That could only come from a .NET programmer.

  10. tadanderson says:

    I agree with Arnon.  I use UML to create abstraction layers in order to bridge the communication gap between stakeholders (technical and not technical).  The reverse engineering provided by SPARX EA is good enough for me to communicate a system's intention.

    I like the new arch tools in 2010, but they only provide reverse engineering value right now.

    I wish MS would concentrate on documentation (Word, Excel, and HTML) out of the diagrams created in VS2010.  Also work on adding notes (to the entities – not to the diagram) and other attributes to the entities.  Right now the diagrams in VS 2010 are worthless when it comes to educating my stakeholders so we are sticking with SPARX.  Generating docs into HTML makes it easy to keep all docs live and current throughout iterations, and then RTF generation for milestone deliverables.

    MDA is a nice thought, and I am sure there are domains that benefit from model first development.  I personally have not seen a company that found the extra effort to accomplish it worthwhile.  The closest I have seen is when producing software product lines.  The variability modeling is very valuable, but that is accomplished today with UML and is usually abstracted to some degree also.

  11. Erik Engbrecht says:


    Doxygen is an example of a tool that automatically generates diagrams from code, and I've seen a lot of others that take the same approach.…/diagrams.html

  12. Anil says:

    Thanks Erik…will look at that tool.

Skip to main content