Will Modeling Services Work with My UML Tool?
<Author’s note>At the first of the year I started a sweet new gig working on the Modeling Services Repository, focusing on the UML Domain. My nefarious plan (let’s hope I succeed) is to bring the perspective of Big IT to the development Modeling Services features.</Author’s note>
As detailed on the UML Domain’s MSDN page, the UML Domain has been engineered to work with any UML tooling that can emit XML files that are compliant with the XML Metadata Interchange (XMI) specification, the UML v2.1.1 Superstructure specification, and the Level 3 Merged Complete Meta Object Facility (L3 Merged CMOF).
As an IT guy I would look at that and say (and I did say when I was in MSIT) , “Great, the UML Domain is standards-based. Sweet. Does that mean that my UML tool will work with the Repository?”
Right now the answer to that question requires some knowledge of the standards listed above. To help out early adopters of the UML Domain, this post will provide a very brief overview of how to use these standards to determine if your UML tool will work with the UML Domain in the Modeling Services November 2009 CTP.
NOTE – As Sonu points out, and was demonstrated at PDC last year, the current CTP works out of the box with XMI files emitted by both Eclipse UML2 and Rational Software Modeler/Architect.
XMI – Defining the XML Shape
The main purpose of XMI is to define how the XML elements are shaped within an XMI file. The XMI spec also defines a mechanism for how one XMI element references another, even across XMI files. This referencing mechanism is needed as it is a legal scenario for a single UML model to be serialized to more than one XMI file. Generally speaking, if you look at the XMI emitted by your tool and you see something like the following XML snippets at the top of the file, that’s a good indication that you’ve got the XMI aspect of working with the UML Domain covered:
1: <uml:Package xmi:version="2.1" xmlns:xmi="https://schema.omg.org/spec/XMI/2.1"...>
2: - or -
3: <xmi:XMI xmi:version="2.1" xmlns:xmi="https://schema.omg.org/spec/XMI/2.1"...>
UML Superstructure – the Data Model of UML Diagram
I would argue that the best way to think of the UML Superstructure specification is that it defines the data model (metamodel) for all the UML diagrams. Take a Sequence diagram as an example. There are a quite a number of visual elements that you can place on a Sequence diagram – Lifelines, Fragments, Messages, etc, etc. The UML Superstructure defines entities (metaclasses) for all these visual elements and also defines the relationships (associations) between them. Just like many database tables are needed to represent an Order Management system, many UML Superstructure entities are needed to represent Sequence, Class, or Deployment diagrams. Again, if you look at the XMI emitted by your tool and you see something like the following XML snippet, that’s another indication that your UML tool is using the right version of the UML data model to work with Modeling Services:
1: <uml:Package xmlns:uml="https://schema.omg.org/spec/UML/2.1.1"...>
L3 Merged CMOF – Defining the XML Elements and Attributes
Think of the L3 Merged CMOF (or just CMOF) as the bridge between XMI and the UML Superstructure. The CMOF defines how the UML data model can be represented in XML, where the XML can be shaped by XMI. Again going to the relational metaphor, the CMOF is analogous to DDL that defines how a relational data model can be represented in physical database tables. This is (as with many things UML-related) pretty abstract, so an example might be helpful. I’ll use the example of Messages, which are used extensively in Sequence diagrams to specify the calls between objects.
Putting it Together – UML Messages in XMI
The following represents a subset of the CMOF definition for a Message:
1: <ownedMember xmi:type="cmof:Class" xmi:id="Message" name="Message" superClass="NamedElement">
2: ...
3: <ownedAttribute xmi:type="cmof:Property" xmi:id="Message-receiveEvent" name="receiveEvent" lower="0" type="MessageEnd" association="A_receiveEvent_message">
4: <ownedComment xmi:type="cmof:Comment" xmi:id="Message-receiveEvent-_ownedComment.0" annotatedElement="Message-receiveEvent">
5: <body>References the Receiving of the Message</body>
6: </ownedComment>
7: </ownedAttribute>
8: <ownedAttribute xmi:type="cmof:Property" xmi:id="Message-sendEvent" name="sendEvent" lower="0" type="MessageEnd" association="A_sendEvent_message">
9: <ownedComment xmi:type="cmof:Comment" xmi:id="Message-sendEvent-_ownedComment.0" annotatedElement="Message-sendEvent">
10: <body>References the Sending of the Message.</body>
11: </ownedComment>
12: </ownedAttribute>
13: ...
14: </ownedMember>
The snipped above defines that every Message has a receiveEvent and sendEvent attribute and that these attributes are of type MessageEnd (lines 3 and 8 of the snippet). This is relatively intuitive as the lifecycle of a Message is logically bounded by the message being sent and eventually received.
A compliant XMI file will have Message XML elements with receiveEvent and sendEvent attributes. Here’s a snippet (with some attributes elided) from a compliant XMI file:
1: <message xmi:type="uml:Message"...receiveEvent="_x_nG94LPEd6HkMeoxaQQ8A" sendEvent="_x_nG9oLPEd6HkMeoxaQQ8A"...>
Sure enough, the snippet above has the receiveEvent and sendEvent attributes as defined by CMOF and they refer to some other elements in the XMI file. Here’s a snippet from the compliant XMI file that shows all three elements (the Message and the two referenced elements) together:
1: <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_x_nG9oLPEd6HkMeoxaQQ8A"...message="_x_nHEoLPEd6HkMeoxaQQ8A"/>
2: <fragment xmi:type="uml:MessageOccurrenceSpecification" xmi:id="_x_nG94LPEd6HkMeoxaQQ8A"...message="_x_nHEoLPEd6HkMeoxaQQ8A"/>
3: <message xmi:type="uml:Message"...receiveEvent="_x_nG94LPEd6HkMeoxaQQ8A" sendEvent="_x_nG9oLPEd6HkMeoxaQQ8A"...>
The XMI snippet above illustrates the relationships between the XML elements. Both elements on lines 1 and 2 in the snippet above reference the Message element on line 3. Conversely, the Message element references each of the MessageOccurrenceSpecification elements.
Hey, wait a minute! Didn’t the CMOF specify that the receiveEvent and sendEvent attributes have to be of type MessageEnd? Let’s go back to the CMOF and check out MessageOccurrenceSpecification:
1: <ownedMember xmi:type="cmof:Class" xmi:id="MessageOccurrenceSpecification" name="MessageOccurrenceSpecification" superClass="MessageEnd OccurrenceSpecification">
The above snipped defines MessageOccurrenceSpecification inheriting from MessageEnd and OccurrenceSpecification, so everything is kosher.
A Counter Example – Close, but No Cigar
Here’s an elided counter example where the XMI is almost compliant with the standards required by the UML Domain:
1: <fragment xmi:type="uml:OccurrenceSpecification" xmi:id="FR000003_6B49_4614_81E5_6F404D70D49A".../>
2: <fragment xmi:type="uml:OccurrenceSpecification" xmi:id="FR000005_8107_4277_B508_8691B2263C60".../>
3: <message xmi:type="uml:Message"...sendEvent="FR000003_6B49_4614_81E5_6F404D70D49A" receiveEvent="FR000005_8107_4277_B508_8691B2263C60"/>
Looks pretty good at first glance, but closer inspection reveals the problem – the Message element’s receiveEvent and sendEvent attributes are referencing elements of type OccurrenceSpecification. Taking a look at the CMOF definition for OccurrenceSpecification:
1: <ownedMember xmi:type="cmof:Class" xmi:id="OccurrenceSpecification" name="OccurrenceSpecification" superClass="InteractionFragment">
Yep, OccurrenceSpecifications are not MessageEnds so this XMI file is non-compliant and will not work with the UML Domain.
Feedback Wanted
Hopefully some folks will find this post useful and they’ll take the UML Domain out for a spin.
BTW – If you’re a Microsoft customer, Microsoft Partner, an ISV, or just a modeling junkie, please send me any feedback on the UML Domain that you may have – good and bad (sometimes the bad is better).