Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Read part 1, part 2, part 3 and part 4.

Models are an essential part of system analysis and design, be they specified in UML or defined by the structure of software artifacts such as XML schemas. However, models that are tied too closely to today's deployment technology may be short-lived. If your company decides to switch from J2EE to Microsoft's .NET, will your system's design survive the migration? The answer is yes, if you build in resilience from the start by using a model-driven architecture (MDA). MDA enables a separation of domain models from specific deployment platforms (see OMG's MDA resources at www.omg.org/mda).

Model Transformation
Let's examine an MDA in which a generic purchase-order specification is refined into two platform-specific models (PSMs) for deployment, one to XML Schema and the other to an Oracle database. Platform-independent models (PIMs) are the cornerstone of distributed systems. Otherwise, without a shared domain model, similar concepts must be designed for each platform, and then those implementations must be synchronized and integrated—the classic headache when dealing with legacy systems.

From the Universal to the Specific This UML diagram depicts the transformation of a generic model to specific platforms in a model-driven architecture. The direction of arrows in this diagram indicates dependency, not the sequence of development process flow. One approach is to move from left to right in this diagram, following a model-driven design in which you first create a platform-independent UML model, then refine it to various platform-specific models and ultimately generate the code. Alternatively, you can start with existing components such as an industry-standard XML schema or a legacy database, and reverse-engineer those implementation languages to platform-specific and platform-independent models.

Platform-specific models are designed to meet the unique needs of a deployment environment and its users. For example, the human readability of XML documents is often an important consideration, and specific design choices must be made that aren't relevant in a platform-independent model. One specification doesn't define all requirements as the design process moves toward the right in this diagram (see "From the Universal to the Specific"). However, at least in the case of XML schema design, it's possible to automate most or all of these transformations, optionally supplemented by human guidance.

I've found it helpful to think in terms of model transformation instead of code generation when creating tools that support XML application design. Implementations in XML Schema, Java or SQL DDL are all models specified using their respective metamodels. To generate an XML Schema from UML, I transform an instance of the UML metamodel to an instance of the XML Schema metamodel. I also transform from one model to another when I reverse-engineer a schema to UML.

Thus, a platform-specific model for XML Schema within UML should have an unambiguous transformational mapping to or from structures in the XML Schema language. But there's more than one way to skin a cat, and this choice is also related to the way in which the PSM is mapped to a PIM in UML. Let's compare two techniques for defining this mapping.

Mapping With a UML Profile
My preferred approach for mapping between a PIM and a PSM for XML Schema is to define a UML profile that adds XML-specific definitions to a UML model. With this method, the only difference between a PIM and PSM is the addition or subtraction of UML profile information, which is composed of stereotypes and tagged value properties that extend the core UML metamodel for XML design.

When reverse-engineering a previously defined XML Schema to UML, I create a logical domain model that includes profile definitions required to re-create an equivalent schema. The PSM may not be structurally identical to the schema (for example, a child element in XML may be mapped to a UML attribute), but the profile stereotypes and tags capture this difference. Then, to create a PIM, I simply remove the XML-specific profile information from this view in UML.

In an alternative approach, I define a PSM that is structurally identical to the implementation language. In a relational database, the PSM includes a one-to-one correspondence between classes in UML and tables in the database. The platform-specific model in UML also includes attributes for all primary and foreign keys, and separate classes are included for many-to-many associations.

However, this PSM may not represent the good conceptual-level view desired for a PIM domain model. A conceptual view should be close to the terms and structure used by human experts, whereas the PSM must conform to the implementation language. So, to map between the PIM and PSM using this approach, the UML classes and relationships may require significant structural transformation, in addition to the use of a UML profile.

This second approach is used by the Rational Rose UML modeling tool for both database modeling and DTD modeling. Rose does not yet include support for XML Schemas. In the case of the Rose PSM for DTD design, each child element in the XML structure is represented as a first-class object in UML, even if it represents a simple string value. To create a PIM from a reverse-engineered model, the PSM must be transformed to a more logical object-oriented structure. As a result, the PIM and PSM are two completely separate model instances, or possibly two packages within a parent model.

Platform-Independent Model This UML diagram shows a platform-independent model created from the xCBL vocabulary specification for order management. This small excerpt illustrates the OrderSummary information that is part of each Order. This diagram was created by reverse-engineering the XML Schema for xCBL 3.5 into a platform-specific UML model. Profile information was then suppressed to create this view.

Purchase Order PIM
Our next example shows a small piece of a platform-independent model for purchase orders, taken directly from the XML Common Business Language (xCBL) version 3.5, developed by Commerce One for business-to-business integration (see www.xcbl.org). The diagram (see "Platform-Independent Model") depicts an excerpt from the OrderSummary message structure in xCBL, which is a very small subset of the order-processing vocabulary definition. The UML class diagrams for all xCBL messages related to order processing fill about 10 pages when printed with a very small font. Even so, it's much easier to gain a quick understanding of the conceptual model for orders using these diagrams, instead of searching through the schema documents or the HTML that was generated from the schema.

Using a W3C XML Schema for xCBL as the starting point, I took the following steps to transform the model, using the mapping approach previously described.

1. Transform the XML Schema from Order.xsd to a UML PSM, including UML profile stereotypes and tagged value properties.
2. Remove the UML profile information to create a PIM.
3. Using the PSM and profile data, generate a RELAX NG schema that can validate the same XML document instances (see www.oasis-open.org/com mittees/relax-ng/ for the RELAX NG schema language specification, which will be submitted for ISO standardization). In some situations, RELAX NG has stronger validation capabilities than the W3C XML Schema.
4. I'm working on a transformation from the PSM to Java classes that serialize and deserialize these same XML documents, implementing the Java Architecture for XML Binding (JAXB) draft specification from Sun (see http://java.sun.com/xml/jaxb/).

All of these transformations focus on UML class diagrams that represent models of the information content specified with XML schemas. However, the same MDA approach applies equally well to the service interface, message interaction and business process models that are essential to Web services.

Many of the early Web services implemented using SOAP are limited to simple request-response transactions. A set of related transactions managed within a complete business process is often referred to as an orchestration or choreography by B2B software vendors. As a complement to a sequence diagram, a UML activity diagram could be created for the larger business process model; this would also be a PIM that's independent of its implementation in a particular workflow execution environment.

There are several proposed representation languages for process models, in addition to many proprietary workflow engine APIs. Two of the contenders for process flow definitions in XML format are closely coupled to other Web service specifications-XML Schema is used to define message content, and WSDL defines interfaces to process activities. The Web Services Flow Language (WSFL) is proposed by IBM, and the XLANG process design language is proposed by Microsoft. Their tight coupling with Web services enables these process models to be used as implementation languages for process management.

I hope that these alternative proposals for process modeling languages will be combined and submitted to a standards body. However, by using UML to capture a platform-independent process model, it may be possible to generate several process languages from a common specification.

Driven or Assisted?
In an ideal world, every industry standards group would define platform-independent UML models of their APIs or XML vocabularies. We would then simply grab that model, integrate it into our platform-specific architecture and generate code that conforms to the standard vocabulary. But we don't live in Shangri-La. There are currently hundreds of industry consortia defining "standard" XML vocabularies based on several different schema languages.

Also, many developers prefer to work within the platform-specific technologies that they know and love. XML designers think in terms of XML-driven architecture. Some see UML as a useful tool for producing diagrams of their schemas and for assisting the integration of heterogeneous systems. Others see UML as a good modeling tool for generating XML schemas, but may not use it for generating associated Java code.

Order Processing Message Interactions This PIM shows message interactions as defined in the xCBL specification. Even though they're intended for exchanging XML documents, the same transactions could be implemented on other middleware. The diagram shows a sequence of six messages, but it's basically three messages passed through an intermediary. A complete business process description might include the end-to-end flow of requesting vendor price quotes, internal purchase requisition and approval, escalation of approval for large orders, order submittal, order acknowledgment, change orders, shipment confirmation and tracking, and invoicing.

Yet the vision behind MDA is still a useful one. In keeping with the current spirit of agility, we need to make practical use of all design artifacts with a minimum of fuss, and focus on delivering systems that work. Instead of viewing the model-driven architecture approach shown in "From the Universal to the Specific" as necessarily relying on platform-independent models that are created in the beginning, I take a pragmatic approach and think in terms of model-assisted design—in which you can start at any point in the development process, transforming your application model to other representations.

In my next two articles in this series, we'll continue the discussion of these transformation techniques for XML.

RELATED ARTICLES ZigBee Alliance, DLMS User Assoc Collaborate on Metering Data Compatibility Embarcadero Takes DBMS Admin Into the Cloud McObject Updates eXtremeDB Real-Time Database System IBM Offers Free Public Cloud Beta For Software Development Zend, Oracle Hook Up for Enterprise-Class Linux and PHP		TOP 5 ARTICLES No Top Articles.