Additional information

Design Rationale

UML is a modeling language for object-oriented software systems with a strong emphasis on a graphical representation. It is deployed throughout the software development process and there is a wide variety of tools that can be utilized during this process. Tools vary greatly: there is an extensive range geared to design the diagrams, to check the consistency of models, to store them for persistence or for versioning, for generating code, for preparing demonstrations, presentations or documentation and many more applications. The ability to seamlessly use and combine all of these various tools trouble free is highly valuable and desirable. Accordingly, a mechanism for representing (and hence exchanging) model information was included in the first UML standard. However, the mechanism laid out in UML 1.x merely supports the definition of elements in a model. While this is essential for tools that check the consistency of a model or generate code, this information is not sufficient for graphically oriented tools. This thus excludes a wide variety of tools that make use of graphical information, including UML tools themselves. In this respect, the model interchange mechanism of UML 1.x falls short and the need to correct this deficiency has been recognized and addressed by the OMG.

The general mechanism applied within the OMG to transport meta-information is XMI. XMI is an application of XML which lends itself to transporting information that is highly internally referential. Both object-oriented models and the models of such models fall into this category but are only one example. XMI was applied to transport UML models by generating a special DTD through applying the rules of XMI to the concrete UML metamodel. To distinguish between XMI in general and its application to UML, we will refer to the latter as XMI[UML] in this document. This mechanism has proved to be highly useful despite the fact that graphical information was not included.

UML diagrams, just like UML models, can be described using a metamodel. This document suggests a separate metamodel for diagram information that can simply be added as a separate package to the existing metamodel of UML. And just as with the metamodel of UML, XMI can be applied to transport instances of this diagram metamodel. The corresponding DTD (which simply extends the DTD of XMI[UML]) is generated directly from the metamodel and provided in this document. This format will be referred to as XMI[DI] here. The conjunction of both, which makes up the complete model interchange mechanism, will be denoted as XMI[UML+DI], or simply as XMI for brevity.

In the current version, one DTD is generated, describing the XMI[UML] and the XMI[DI] part. In next version of the specification, using XLink for referencing other ModelElements, both parts can be placed in different files, allowing different DTDs for each part to be generated.

The metamodel proposed in this document conforms to the MOF metamodel facility. XMI defines how to create a DTD or a schema from an MOF-compliant metamodel and how this is to be applied to XMI. Thus, once an MOF-compliant metamodel has been agreed on, its representation in XMI and the corresponding DTD is taken care of.

The metamodel itself was developed with two key objectives in mind. First, it should flexibly extend the existing UML metamodel (as well as future revisions) without interfering with it and without modifying it. At the same time it should carry as little redundant information as possible and instead reference the UML metamodel to access this information. Second, it should allow any tool to easily render the diagram from the given information. This, of course, includes UML tools but also web browsers, office suites, graphical editors, etc.

The tools addressed are very different in their needs. While UML tools usually enable the rendering of model elements to lines and text themselves, text editing tools have no knowledge at all about model elements and require a diagram to be in a common graphical format. And graphic tools typically require a rich vector-oriented format for manipulating and scaling.

SVG, the scalable vector graphic format, is a new W3C standard that promises to be supported by a wide variety of these tools. It is based on XML and can easily be read in, processed, and transformed into many other formats. It is equally suited for text tools, office suites, and graphic tools. Moreover, it is suitable for web browsers that will soon support it directly (but in the interim can use a freely available Adobe plugin).

However, SVG is not a well-suited mechanism for UML tools. UML tools do not require solely the lines and text but need information at a higher level for they do not merely display the diagrams graphically they also call for a semantic understanding of the ModelElements that are represented by the graphical primitives.

Yet one of the great advantages of XML is that data expressed in one XML data format can easily be transformed into a different XML data format as long as all required information is present. Therefore this specification suggests a metamodel transported using XMI[DI] and provides a transformation from XMI[UML+DI] to SVG using XSLT. This approach satisfies the needs of the widest range of tools. All other required formats can then be produced from this.

So, what is the abstraction that commonly expresses the additional information to allow interchange for all diagrams in UML? While one alternative would be to introduce special classes for each and every kind of shape that UML diagrams consist of, if UML is to be extended or its scope broadened or if the core mechanisms are to be reusable for other modeling notations, this approach seems too inflexible. The diagram interchange should not restrict the extensibility of UML. If possible, the diagram interchange mechanism should not have a notion of concrete shapes or other elements. The drawing of the concrete forms of the shapes used lie in the responsibility of the UML tools or of an SVG renderer.

It can be observed that most diagrams in UML follow the graph schema as known from graph theory: they consist of nodes (which may be rectangles, ovals, circles or other shapes) and edges (connecting lines between the nodes with different arrows and shapes at the ends). Nodes can contain compartments and annotations; edges can have annotations attached to them. Some nodes can be nested in others, with edges connecting two nodes (in some cases they may also connect edges).

The graph schema is a very powerful, well understood, abstraction that is employed in many areas of visual modeling. It is the abstraction used by this specification since it proves to be fully sufficient, as will be discussed in this document. Most UML diagrams have a natural and straightforward mapping to a graph. This is also the case for class diagrams, use case diagrams, collaboration diagrams, object diagrams, component diagrams, and deployment diagrams. In the current form of the UML, it is only sequence diagrams that do not have such a natural mapping to nodes and edges; yet a mapping can clearly be found. It is argued that, although the graph based approach may not be the obvious choice for all diagram types, it is well suited for most and fully sufficient to represent any current and future UML diagram types.