XMLmodeling News

January 28, 2003
volume one issue two

Visit 
XMLmodeling.com 
to learn more about modeling XML applications.

There is a steady increase of interest in mapping between UML and XML Schema, but also a steady increase in alternative approaches. I’ve received numerous inquiries from students who are writing master’s theses on this topic (mostly from Europe) and a related inquiry about mapping between UML and ASN.1 schemas. Just as I was finishing this newsletter, I heard that UN/CEFACT is creating a project for defining a mapping from UML to XML Schema.

This newsletter summarizes our work on this topic and looks forward to possible next steps.  As always, we welcome your feedback and suggestions.

One of the principal advantages of using UML when designing XML vocabularies is that the model can serve as a specification which is independent of a particular schema language implementation. W3C XML Schema is the most common choice right now, but we hope that business vocabularies (and other non-business technical markup languages) have a long life and will be implemented using alternative new schema languages.

To achieve this goal, we need to define a complete and flexible mapping between UML and each implementation language. Given that UML was originally intended for object-oriented analysis and design, the mapping is most straightforward for languages that have an object-oriented flavor. This is true of XML Schemas.

The XSD mapping defined in Appendix C of Modeling XML Applications with UML has held up very well since it was created three years ago. Only minor adjustments have been made based on user feedback and experience with large complex schemas.

UML Profile for XML Schema

A bi-directional mapping between UML and schemas is specified in the form of a UML Profile. The purpose of a UML profile for this or any other use is to extend the UML modeling language with constructs unique to an implementation language, analysis method, or application domain. The profile extension mechanism is part of the UML standard; it was expanded in the recent UML version 1.4 and will be further expanded when UML 2.0 is adopted this year.

A UML profile (pre version 2.0) is composed of three constructs: stereotypes, tagged value properties, and constraints. A stereotype defines a specialized kind of UML element; for example, the XSDcomplexType stereotype defines a specialized kind of UML Class, and XSDschema defines a specialized kind of UML package. Tagged values define properties of these stereotyped elements. So the XSDschema stereotype includes a targetNamespace property. By assigning this stereotype to a UML package and setting a value for this property, we have augmented the UML modeling language with information used to generate a complete XML Schema document from an abstract vocabulary model. Similar stereotypes and properties are defined for all XML Schema constructs.

A profile constraint specifies rules about how and where stereotypes and their tagged values can be used in a model. These rules should include what are often called co-constraints: how the value of one property constrains the values of other properties. The constraints may also impose additional restrictions on the general UML modeling language. For example, a class with the XSDsimpleType stereotype only can be a subclass of one other class having the same stereotype; although, a class with the XSDcomplexType stereotype can extend a class with XSDsimpleType.

We will post a complete HTML version of our UML profile for XML Schema within the next week, see XMLmodeling.com.

UML Profiles for Higher-Level Vocabularies

This first UML profile provides a flexible foundation with a direct mapping to XSD implementation. It can support general purpose schema design from within a UML modeling tool and also enables reverse engineering of arbitrary schemas into UML. However, it’s unlikely that one profile will suffice for all XML vocabulary specification work. A family of profiles is needed, where each one is suited to a particular specification and reuse methodology.

Instead of using the XML Schema profile to map UML constructs directly onto XML Schema constructs (e.g. a Class onto a complexType), a UML profile can be defined in terms of a more abstract vocabulary specification, such as the ebXML Core Components.

The Universal Business Language (UBL) technical committee at OASIS has begun creating a library of reusable core components and then using those to construct aggregate business documents for Order and Invoice. See the new OASIS UBL library draft release at: http://www.oasis-open.org/committees/ubl/lcsc/0p70/.

Although the UBL committee did not use UML models to design its components, those schemas are easily mapped into UML class diagrams via reverse engineering. Future design work could be accomplished by creating UML models of the core components contained in these vocabulary definitions, annotating the models with an ebXML profile, and generating schemas from the model.

Back to top

I am very interested in your input on prospective UML profiles for vocabulary development. In addition to the UBL work, I’m aware of other UML/XSD mapping efforts related to SWIFT, ISO, and UN/CEFACT. And I’m sure there are others.

I have started initial work on a UML profile for ebXML vocabulary design, based on the results of the Universal Business Language (UBL) technical committee at OASIS. To create a UML profile that supports this methodology, I have defined UML stereotypes for core component definitions, e.g. basic business information entity (BBIE) and aggregate business information entity (ABIE). In the UBL methodology, each entity type is specified by a set of parameters; for example, objectClassTerm, propertyTerm, and businessTerm. These parameters are included as tagged value properties on a UML stereotype in the profile. UBL’s naming and design rules are then applied to generate compliant schemas from these annotated UML models.

I have not yet written a schema generator based on this ebXML UML profile, but will build a prototype in the near future. One approach that I’ll consider is to apply a two step mapping: from the ebXML profile, to the XSD profile, to a schema implementation. The XSD profile would not be visible to business modelers, but this well-tested mapping and its current implementation would be used to produce schema output from the UML model. In this design, the UBL’s naming and design rules would assign a set of stereotypes and property values in the XSD profile, based on the ebXML stereotype and its property values.

I have designed the UML profile for XSD to be equally applicable when generating schemas from UML and reverse engineering existing schemas into UML models. An overriding concern was to balance ease of use with sufficient flexibility to handle all common schema designs. Goals included:

• Enable rapid development of “good” schemas, without requiring the user to have in-depth knowledge of XML Schema syntax and capabilities.
• Use default profile preferences to enable schema generation from any UML model, without needing to customize the model with stereotypes. Default preferences may be modified to permit organizational standards for “good” schemas.
• Profile preferences cascade down through nested packages to contained classes, attributes, and associations. This yields rapid design with minimal duplication of property settings.

We are planning several XML modeling workshops in Europe and the United States that will cover all of these topics in detail with hands-on exercises. Please contact us if you would like to attend a four-day workshop in your area, or if you have suggestions for improving its content. Visit XMLmodeling.com, where an open-enrollment workshop description will be posted in the next week or so.

Back to top

The mapping between UML and XSD includes package/schema modularity that is essential when building a reuse library. In UML, the modularity is shown as packages (with a file folder icons) and dependencies are shown as dotted line arrows between packages.

Using the reverse engineering capabilities of hyperModel, the UBL schema for Order is imported into a UML model. This model was saved to an XMI file and opened in Rational Rose. The following diagram illustrates UBL modularity and dependency as a UML package diagram.

Although not shown in the diagram, each resulting package in the UML model includes tagged value properties for targetNamespace and targetNamespacePrefix that hold the corresponding values from the original schemas. The stereotypes and properties are assigned according to the UML profile for XML Schema. When generating a schema for a package in this UML model, all dependencies are checked and generated as <xsd:include> or <xsd:import> statements, depending on whether the dependent package has the same or a different targetNamespace property.

For comparison, the following diagram was reverse engineered from the “AddSalesOrder” BOD in the OAGIS 8.0 schemas published by the Open Applications Group. Their components are decomposed into a larger number of functionally related schema files, which are mapped into UML packages. In their design, the Components and Order packages contain the largest number of definitions that are similar to the UBL library.

Back to top

The UML diagrams included in Annex C of the UBL library release were automatically reverse engineered from their schema definitions through use of our hyperModel application. hyperModel implements the complete bi-directional UML to XSD mapping discussed in this newsletter, and also supports a unique point-and-click style of diagram creation and browsing. Diagrams like those included in the UBL release can be created in a matter of minutes.

hyperModel version 1.2 is planned for release in late February. It includes significant improvements in diagram presentation and browsing, and the ability to easily save diagrams in SVG, GIF, PNG, JPG, and TIFF formats. Similar diagrams can be created in the current hyperModel 1.1. And no need to wait – your purchase of the current release includes a free upgrade!

Use of Profiles in UML Modeling Tools

Many UML tools include support for defining UML profiles and using those profiles to customize the application interface. Minimally, stereotype names are predefined in pull-down lists so that a UML package or class shows only the appropriate stereotypes that may be assigned, e.g. XSDcomplexType for a class but not for a package. In addition, a UML tool should provide a list of profile properties that are specific to the assigned stereotype, e.g. a modelGroup property for XSDcomplexType.

For more information about hyperModel, and to find out how you can download your free copy, please visit XMLmodeling.com.

Back to top