Oslo and UML
It’s been a while since my last posting. Why? The truth is quite simple – about five months ago I became involved in a small team building some specific content for our Oslo repository. This team was working using Scrum techniques with two week milestones. Initially I was supposed to be “part-time” on the project – a kind of advisor – as my duties at Microsoft as an Architect usually involve me in cross-divisional work, “strategic” projects, and early-stage prototypes. But I quickly realized that it’s hard to be a useful member of a fast moving multi-disciplinary team working on tight schedules if you are not completely engaged. Consequently I have thrown myself right into this project, and have had a blast ignoring all other duties just to get something done, and have fallen right back into check-ins, code reviews, triaging, and bug debts. Not to mention working long hours and weekends – the not-so-fun partJ.
Now I can reveal that the “specific content” we’ve been working on is an M implementation of the UML2 (version 2. 2) metamodel – which will be released as part of the Oslo CTP to be made public next week. We’ve taken (a subset of) the OMG’s specifications for UML2 (available from the OMG site here), used the M language to represent the classes described in the specification, created M extents using a mapping of the classes to extents that I’ll describe in more detail later, and created storage structures in the Oslo repository into which we can load UML2 models using a loader that is also part of the upcoming CTP. I’ll give a few more details of the technical specifics in a moment, but some readers may be already asking the question Why would the Oslo team do this?
Well, there are a couple of very good reasons why we should place a bet on UML in this way:
1. Our customers have told us that increasingly UML2-based tools are used as part of their development processes. The usage varies from non-rigorous drawings used for communications, to rigorous specifications used in sophisticated ways as part of various model-driven development methods. Often tools from several different vendors are used, and specifically in the case of UML models used in model-driven development, it is challenging to impose standards on their use, to ensure UML elements are reused consistently across models, and to conduct analyses (such as conformance to the UML specification) upon them. By placing these models into a database, in our case the Oslo repository, we can address all of these challenges. Once loaded into the repository, customers can search, analyze, query and add linkages between elements in various models. Our colleagues in Visual Studio have of course also responded to this customer demand, and are in the process of adding to Visual Studio Team Architect (Dev10) a set of UML2 modeling tools. Once these tools are released, we plan to have loaders to allow VSTA customers to load their UML models into the Oslo repository, and we’ll commit to supporting the main variations of the industry-standard XMI format for loading models created with third party tools into the Oslo repository.
2. UML2 contains a collection of specific sub-models which address many of the needs of analysts, architects, developers, testers and IT staff. In early releases of the Oslo CTP, we had provided M models for some of these domains (Composite Application Structure, Workflow, etc.), which were a mixture of Microsoft platform-specific concepts and general platform-independent concepts. We provided these models specifically to encourage model-driven development upon our platform. But again, feedback from our customers led us to understand that where possible, they would like to use UML2 for concepts that are defined in the OMG specification or easily extended. Consequently we have decided to double-down on our provision for UML2 as a set of modeling concepts. Naturally these concepts may then be inter-related as required to other non-UML2 domains represented as DSLs or overlapping domains already covered by DSLs. In any case, once we have the UML2 and non-UML2 information in the Oslo repository, other tools such as model-to-model transformation tools and code generators now have a common place to look up and insert UML model elements. Runtimes directly targeting the repository may utilize metadata irrespective of which modeling standard was used to create it.
Some folks may be surprised by a perceived about-turn towards UML2. We, as have many other industry thought-leaders, have criticized UML for its complexity and extension mechanisms. I’ve seen its specification reviewed as anything from an over-complex, compromise-laden monstrosity to a pinnacle of human achievement. Suffice to say that having spent the last few months deeply immersed in it, my judgment tends to the latter. Sure the specification has bugs and will improve in places in subsequent revisions, but the bulk of the concepts are proving themselves useful and workable as evidenced by a growing number of tools, and as variants of XMI reduce in number, interoperability between tools will increase.
So, back to the Oslo CTP. The UML2 model we have provided is a subset of the full specification. There are whole domains missing, and domains present are not complete. However the loader we have provided can load a restricted family of XMI artifacts into the repository. Specifically, only a few of the specification’s OCL-based constraints are represented in the M source. When we finally ship Oslo, we intend to have the whole model built to OMG Level 3 compliance. Our main goal is to seek feedback and comments on our approach and garner scenarios from early reviewers that can help us shape the product’s future.
Anyone who already knows the UML2 specification in detail will understand the complexity involved in translating such a complex, intertwined class model that relies heavily on long trails of multiple inheritance into essentially a relational style model using a language such as M. We have developed a set of M patterns which we apply to patterns of UML model elements (related to industry standard approaches for object to relational transformation) which we’ll publish in further articles and blog entries. Further details of the UML2 Loader will also appear subsequently.
We await your comments. Many thanks.