Back from the OMG meeting in Cambridge

I just arrived back from the Object Management Group’s September meeting in Cambridge (the one across the river from Boston, not the one in UK where I went to university and go to work).

I want to make UML more relevant to mainstream developers and a better match for modern platforms, so that it and its derivatives can play seamlessly and add value to modern development environments.  We’re making decent progress with this. UML 2.4 is almost finished, UML 2.5 is in the works, and discussions for the future of UML and its associated technologies past 2.5 are well under way.

UML 2.4 has cleaned up the UML metamodel considerably, and also clarified some ambiguous constructs that inhibited effective implementation, especially around sequence diagrams and profiles.  UML 2.4 will be aligned with related standards MOF 2.4 and XMI 2.4. The end result will be that UML 2.4 will be defined in itself, which considerably simplifies the task of implementing it.

The submission team for UML 2.5 has been established.  There now exists a simplified metamodel based on UML 2.4 with all “package merge” removed.  The detailed work of re-writing the simplified specification around that metamodel will take place during 2011. This should make it a lot clearer what UML actually is.

SMOF (MOF support for Semantic Structures) was accepted for adoption as a standard.  This is an important element because it will help enable the eventual refactoring/simplification/unbundling of UML, hence enabling it to be a better match to modern technologies.  It now goes into finalization (which I am co-chairing), and should become a published standard towards the end of 2011.

We’re still working on the roadmap past UML 2.5, but I believe that one of the first things on that roadmap should be a replacement of the UML Profile facility with a better-integrated capability based on SMOF.   How UML profiles actually work is a mess, and although some of them are increasingly popular (SysML, SoaML, UPDM, and more) it is increasingly difficult to manage the complexity and confusion that results from the poor definition of the profile mechanism.  Fixing and enhancing this will really help UML derivatives to take off.

Comments (4)

  1. Student says:

    When I came to university I was delighted by UML and thought that this is ultimate "way-of-development" for developers. I was deeply mistaken. I became a developer and I do not know any mainstream developer who uses UML other than small sketches on white-board during coffee brakes, and moreover, anyone who needs it. Sometimes it used by business analysts in specifications, but other that that — thanks, no.

    Mainstream developer  really needs one thing — code editor (thank you Jetbrains).

  2. cbitter says:

    Interesting …

    While the previous post reveals some truth I cannot agree with it. I believe there is relevancy to UML being another reasonable form of abstraction of (software) systems and eventually a well established means to the (somewhat) automatic process of (software hull) generation. The one thing that always hit me with UML is something you touched on in your post  – its complexity and in some ways related verbosity.

    Do we really need all the concepts defined by UML? Also, I believe UML suffers from a problem shared with other (believed-to-be) industry relevant standards a self induced relevancy and tendency to be understandable only if you are fully trained rocket scientist. While its self reference (be defined by itself) is fact, what is it perceivable relevance to the "user" of UML. Does it add to its expressiveness? I assume it has theoretic advantages much like spaces and subspaces (being closed).

    While I believe the concept of class / sequence / and state diagram are somewhat universal (UML really did not invent something here) and expressed in other forms (petri net, state automata, ER diagram), more guidance is necessary to bring it to life and use among "the mainstream developer" (maybe not directly – probably architect and related roles).

  3. Defining UML in itself is simpler than defining it in an obscure dialect of itself (called CMOF) for which almost no tools exist.  The advantage to the user is indirect: it will make it easier for UML to evolve to be simpler and less verbose.  

  4. Cyrille Martraire says:

    I fully agree with the first comment, except my enthusiasm for UML was in my first job in a startup, and also vanished quickly, apart from "UML as sketch" or for very limited diagrams to help visualize a small part of some structure or mechanism.

    I'm also skeptical about using UML to generate executable artifacts, UML does not look any higher-level to me than plain object structure, especially now that we have annotations to precise additional semantics, just like UML stereotypes. As suggested in Domain-driven Design, I prefer the perspective that the code is itself the model, a testable and executable one, perhaps completed with some additional lightweight documentation as text or simple UML diagrams.

    I could become interested in UML again if it could help communicate higher-level concepts (à la functional programming for example) a in really simple and concise way. My feeling is that it is not yet the case.

Skip to main content