Compartilhar via

UML 3 dilemmas

  • Artigo

I’m back from the OMG meeting in Santa Clara.  We talked a lot about the future of UML.  Just about everybody is agreed that we need to create UML 3, but there are some real practical dilemmas.  Currently UML is complicated and it can take a lot of expertise to apply it successfully to any particular situation: “Jack-of-all-trades and master of none”.  OO class modelling is its original domain, but since then it has been bent to apply to many situations including business modelling, requirements, executable models for real time systems, and as a basis for new languages such as SysML.  But even when applied to OO modelling it is not a particularly good fit to any particular OO programming language: C#, C++, and Java are all poorly represented using “vanilla” UML class diagrams.

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.

Comments

  • Anonymous
    December 13, 2010
    Hi Steve, I'm really interested to see the outcome of this.  I'm currently trying to figure out how to integrate our DSL, which describes a lot of the system structure, with the higher level system modeling process in UML, to improve traceability, reduce duplication and close the gap between design and implementation.  The approach you describe of using a kernel of fundamental concepts and building these into multiple domains feels similar to the DSL idea.  Do you think that this could make it easier to bring DSLs more into the modeling process. @jeremyorme

  • Anonymous
    December 13, 2010
    Jeremy - yes, I do think that.  Most DSLs turn out to be some variation on a small variety of types of model - state machines, ER diagrams, flowcharts, etc., but with the details tailored to particular domains.  Currently, UML is overcommitted, so you have the uncomfortable choice of using UML and ignoring the extra bits you don't need, or building a new language from scratch that is like some bit of UML but with only the details that you want.

  • Anonymous
    December 14, 2010
    Steve, I am quite disappointed at the level UML 3 is being steered. I wrote this post a while back: www.ebpml.org/.../mde-the-road-ahead-for-uml to express some of my frustration, and with some recommendations at the end. In effect, UML must break its dependency on OO. OO is just a particular case of a much broader paradigm. U-M-L standard for Unified Modeling Language, in case no has noticed. In fact, UML must break its dependency on any kind of "programming language". In 2010, we need a strong foundation to build solution models (which I find more valuable than problem models), not to write better "code". MDE is the future, not Java or C#. The question is will the OMG deliver on that future or remain anchored in a past that is every day, more irrelevant.

  • Anonymous
    December 14, 2010
    Jean-Jacques - I wrote "provide rich features for extension into multiple domains".  You wrote "UML must break its dependency on OO".  I don't see any disagreement there.  But "MDE is the future" -  that's not what customers tell me. In any case UML must span the present and the future.

  • Anonymous
    December 14, 2010
    Steve, pretty much everyone is using UML as an M3 layer today. Very few people have the patience and the knowledge to understand the semantics of UML and apply them accordingly to create their solution model. The people at Praxeme.org come to mind as being an example of having this patience and knowledge. So you can decide that you are going to rearchitect UML such that it can support more modern concepts, in a more understandable way, but that direction, is, IMHO, hopeless, even as you take a kernel/extensions approach, which is the most sensible one. The real game changer for UML is M3. UML must give an M3 layer that enable everyone to build their solution model (or to let industry groups -not the OMG- create well designed solution models). M3 is the kernel. I have provided an example of what such an M3 layer could be here: www.infoq.com/.../mop. I call it MAF (MetaArchitecture Framework). As long as UML will try to create ties to existing programming language we will remain in this state, where there is definitely value in expressing common semantics, but there is also frustration of UML being no more than a communication tool. If that's what people want, so be it, but as Steve Jobs teaches us, very often, people don't know what they want. my 2c.

  • Anonymous
    December 19, 2010
    Steven, Thank you for an update on the future of UML. I see that customization is getting more attention now in the vision of UML 3. You write "flexible kernel of very fundamental concepts, and provide rich features for extension into multiple domains." How is it different from the current situation? Is the number of concepts is reduced, or is extension mechanism (profiling) changed? An implicit part of UML is also development methodology. What are plans for it in UML 3?

  • Anonymous
    December 19, 2010
    Andriy - It is still too early to say anything definitive about UML 3, because there are many vested interests that have to agree on a way forward.  I certainly hope that the number of concepts is reduced, or at least that the coupling between the concepts is reduced.  Yes, the profiling mechanism is not very well-defined today; it causes a lot of problems and needs to be improved.  UML never claimed to be a development methodology and I don't see that changing.