This is the first time in the history of UML that a complete machine-readable definition of the language is available online, defined as an instance of itself, and with no dangling references.  Only of interest to UML aficionados maybe, but a milestone nonetheless.

From an end-users’ point of view, UML 2.5 will be exactly the same as UML 2.4; so you might wonder why we are doing this.  The goal is to simplify and reorganize the written specification so that we have a fighting chance of refactoring it, modernizing it, and generally making it more useful.  It’s an investment to reduce architectural debt, without which any significant new development of UML would be intractable.

• How to associate data with any UML element by using References.
• How to add decorators to UML elements
• How to add rules to respond to changes in a UML model
• How to define menu commands for UML
• How to handle the user dragging various kinds of object onto a UML diagram:
  • Project Items from Solution Explorer
  • Files from Windows Explorer
  • Shapes from other UML diagrams

We’ve given a lot of attention to making the machine-readable specification of UML 2.4 solid.  That does not mean it is perfect, by any means, but it is a lot better than any earlier version.  The specification of UML 2.4 is itself a UML 2.4 model serialized using XMI 2.4, which can be imported by any UML 2.4-compliant tool.

We’ve now started working on UML 2.5.  From an end-user and tool-vendor perspective, UML 2.5 should be the same as UML 2.4.  The main point of UML 2.5 is to greatly simplify the specification itself, so that future improvements become tractable.  Additional goals of UML 2.5 are to formally specify what diagrams are valid, to correct inaccurate constraints, and to fill in missing ones. I’ll only be satisfied if we reduce the total length of the specification by at least half.

The way to resolve this is to build a flexible kernel of very fundamental concepts, and provide rich features for extension into multiple domains.  The kernel should make as few semantic commitments as possible: for example, no commitment to the meaning of visibility, no distinction between “structural” and “behavioural” features of a classifier, flexible concepts of parameterization, and so on.  For backwards compatibility, existing UML can be defined through one or more profiles or viewpoints on this kernel, which will also enable extensions into many new domains and better matching to existing domains.

The main dilemma is that constructing such a kernel may not carry sufficient business value to get it adopted on its own. There is a lot of investment in UML as it is, and we need to do enough of UML 3 that the new features provide compelling value.  Customers tell me that they would really value deep integration of UML with managed and native code, Entity Framework, Windows Workflow Foundation and other aspects of our platform.  That’s a good incentive for me: define UML 3 so that a first class .Net Profile for UML can be deeply integrated into our tools.  I’ll expect other stakeholders to be able to do the same for their platforms, programming and modelling languages.

I met several old friends, including Jean Bézivin and Philippe Desfray.  Many people introduced themselves to me and wanted to talk about model-driven topics.  Several of them were keen users of DSL Tools and asked about our future plans.  Some were UML users.

I asked everybody I spoke to what they really value in model driven development tools.  These are some of the key points I got from the replies:

• Being able to integrate models tightly with the code
• Being able to integrate models in different domains, e.g. business models and UML models
• Being able to reuse good ideas from UML in custom DSLs without having to deal with the whole thing
• Being able to describe and validate system architectures

It was a very informative and enjoyable day.