Share via

The Road Ahead for UML

  • Article

I have co-written a paper about the future of UML with Ivar Jacobson.  You can find it here.  Let me know what you think!

Comments

  • Anonymous
    June 06, 2010
    Is the UML standard (or profiles for it) evolving to cleanly support any of the following:
  • functional abstractions such as closures (when Java 7 comes out, most major and minor application programming languages will support closures)
  • parametric polymorphism
  • metaprogramming in general (heavily use in Python and Ruby)
  • metaclasses in specific (critical for modeling Python, and probably important for modeling bytecode enhancement which is common in Java) I know that much of this can be force-fit into UML using stereotypes, but the result is not pretty. My general point here is that main-stream programming languages have advanced much more rapidly in terms the level of abstraction they provide than UML has.  Even sketching designs that rely on advanced language features quickly becomes an effort in futility.  This is double frustrating because, as you and Ivar Jacobson point out, UML is a huge language.

  • Anonymous
    June 07, 2010
    Erik, I completely agree, and enabling those kinds of abstractions to be expressed effectively is certainly on my wish list for UML.

  • Anonymous
    June 11, 2010
    Steve, I find the article pretty relevant and representative to some of the structure specifications are evolving into as they mature. The BPMN2.0 specification -which will reach the OMG AB shortly- was originally conceived structurally as described in the article, with minimum set of  BPMN 'elements'  at the core with a series of additional specification layers that are functionally grouped. Interestingly -and taking semantic freedoms- you might look at the BPMN experience as a example of the challenges a much broader UML specification will encounter, when definign the nature of the 'core', in ways that there is enough elements of them that they maintain semantic relevance on their own that allows for the 'drastic' simplification we thrive for. I believe there is a significant discussion to have in this area and a relevant learning experience from the BPMN2.0 workgroup.