XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

Modeling XML Vocabularies with UML: Part III

October 10, 2001

This article is the third installment in a series on using UML to model XML vocabularies. The examples are based on a simple purchase order schema included in the W3C XML Schema Primer, and we've followed an incremental development approach to define and refine this vocabulary model with UML class diagrams. The first objective of this third article is to complete the process of refining the PO model so that the resulting schema is functionally equivalent to the one contained in the XSD Primer.

The second objective is to broaden our perspective for understanding how UML can contribute to the analysis and design of XML applications. This subject is of book-length complexity, one of which I've written one, another I'm planning, although more specific goals are possible if we keep our focus on the design of XML vocabularies. The following list summarizes several goals that guide our work.

Table of Contents

UML Profile for XML Schema

Customizing the PO Schema Design Model

Creating XML Schemas with hyperModel

Schema Modularity and Reuse

Tips for Success

  • Create a valid XML schema from any UML class structure model, as described in the first two parts of this series.
  • Refine the conceptual model to a design model specialized for XML schema by adding stereotypes and properties that are based on a customization profile for UML.
  • Support a bi-directional mapping between UML and XSD, including reverse engineering existing XML schemas into UML models.
  • Design and deploy XML vocabularies by assembling reusable modules.
  • Integrate XML and non-XML information models in UML; to represent, for example, both XML schemas and relational database schemas in a larger system.

Even this relatively narrow scope covers a broad terrain. The following introduction to a UML profile for XML adds a critical step toward all of these goals. These extensions to UML allow schema designers to satisfy specific architectural and deployment requirements, analogous to physical database design in a RDBMS. And these same extensions are necessary when reverse engineering existing schemas into UML because we must map arbitrary schema structures into an object-oriented model. But don't get hung up in the details of the UML profile; in most cases, a few well-placed stereotypes and properties will achieve your design objectives without distracting from the clarity of vision in your conceptual model.

UML Profile for XML Schema

Previous Articles in this Series

Modeling XML Vocabularies with UML: Part One

Modeling XML Vocabularies with UML: Part Two

UML provides a foundation for modeling structure and behavior of most software systems, but there are domain-specific situations that require additional model information to be captured by the analyst beyond what is possible with UML. This issue is solved through the use of UML extension profiles. A UML profile has three key items: stereotypes, tagged values (properties), and constraints. A profile provides a definition of these items and explains how they extend the UML in a particular domain, which is XML schema design in our case.

We had a brief encounter with UML stereotypes previously: <<XSDsimpleType>> was used to indicate that a class should be mapped to a user-defined datatype in the schema. A complete definition of the UML profile for XML Schema is beyond the scope of this article, but it's included in an appendix of my book and soon will be posted on XMLmodeling.com. Three stereotypes are introduced here along with a few tagged value properties. Their use will become clearer in the following section where we apply them to customize the purchase order model.

Each stereotype is assigned to one or more UML constructs that are modified by the profile extension. Each stereotype can be further specified by adding one or more properties that refine its meaning or impact on a model. For example, a stereotype assigned to a UML class extends the meaning of a "class" within the profile's domain and the stereotype's properties are added to the specification of that class in the model. Three stereotypes from the UML Profile for XML Schema are summarized as follows:

<<XSDcomplexType>> on a UML class

  • modelGroup (all | sequence | choice)
  • attributeMapping (element | attribute)
  • roleMapping (element | attribute)
  • elementNameMapping (upperCamelCase | lowerCamelCase | hypenLowerCase | omitElement )

<<XSDelement>> on a UML attribute or association end

  • position (integer value) within a sequence model group
  • anonymousType (true | false)
  • anonymousRole (true | false)

<<XSDattribute>> on a UML attribute or association end

  • use (prohibited | optional | required | fixed)
Comment on this article Share your questions or comments in our forum.
Post your comments

Other stereotypes can be used (e.g. <<XSDsimpleType>> on a UML class or <<XSDfacet>> on a UML attribute) to modify the meaning of those structures in the XML schema without specifying additional properties.

Many of the profile property values can be set as defaults for an entire UML model or for one package within that model. For example, the default modelGroup property can be set to 'sequence' for all classes within the model, instead of setting this property for each class individually. Similarly, the default attributeMapping can be set to 'element' so that all UML attributes are produced as XML elements in the schema, unless overridden for one or more individual classes. Individual UML attributes also can be assigned a stereotype that overrides the class or package default mapping.

Pages: 1, 2, 3

Next Pagearrow