使用 XML：UML、XMI 和代码生成，第 1 部分

Benoit 开始撰写关于 UML 和 XML 模式开发的一系列新文章，这是其中的第一篇，讨论了使用 UML 对 XML 建模的动机。他还介绍了 XML Metadata Interchange（XML 元数据交换，XMI），并简要描述了从 UML 模型自动派生 XML 模式的策略。请您在本文的讨论论坛上与作者及其他读者交流您的想法。（您也可以单击本文顶部或底部的讨论来访问论坛。）
随着 XML 成为主流，人们越来越关心 XML 应用程序的设计。更具体地说，许多组织希望把 XML 应用程序的设计与他们的其他应用程序设计结合起来。采用一种通用的方法——或者至少一组通用的工具——是值得考虑的方向。

就 XML 而言，设计活动主要围绕着数据建模。事实上，因为 XML 是一种标记语言，仅仅涉及到信息的组织——这一点和其他语言是不同的，比如 Java 同时处理数据建模（类继承）和数据操作（方法）。

使用 XML 专栏新的系列文章将探讨使用 UML 建模工具设计 XML 应用程序，如 IBM Rational Rose 和 XSLT，这是其中的第一篇。在这篇介绍性的文章，我将讨论数据建模的基本原理，并介绍在后面三篇文章中将用到的技术。

数据建模
简明牛津词典（牛津大学出版社，2001）关于名词“model”至少有 7 种以上的定义。对于本专栏系列文章而言，下面的定义最合适：“系统及其他的简化（通常是数学化的）描述，以便帮助计算和预测。”这个定义中有三个关键词：简化、描述和帮助。

按照这个定义，模型是关于系统的描述。这一论断很重要，模型不是系统本身，而是系统的形式化表示。具体到 XML 而言，系统由按照特定词汇表编码的文档组成。

这一定义的第二方面说模型是一种简化的表示。它不像所建模的系统那么复杂或者丰富。许多系统都设计用于解决复杂的问题，因此天生就是复杂的。比如，看一看 DocBook 这类复杂的词汇表：它设计用于出版技术数据和文档（其中 Linux 文档就是用 DocNook 出版的）。因为技术书籍和文档很复杂， DOcBook 也很复杂（请参阅参考资料）。

此外，人们能够同时处理的信息量是有限的。多数人在解决一个复杂的问题时，都喜欢（或者需要）把它分解成更小的、更容易管理的问题。建立模型就是为了满足这种需要。模型通过只公开系统的某些特定方面来简化复杂的系统。

定义中最后一个关键词是帮助。模型不是凭空建立的，而是服务于非常具体的目标，它只是更有效地实现特定目标的一种工具。目标从来不是建立模型，而是处理一个系统。

目标的操作特性与前面所述的简化密切相关。简化意味着要选择系统中需要包括的那些成分，和应该抛开的那些成分。选择受模型的目标所控制，比如试图帮助的计算和预测。

简化和建模
无论如何强调模型是实际系统的简化都不过分。同样，除非将其分解成更小的、更简单的成分，要解决一个复杂的系统是不可能的。在实践中，一个模型常常是不够的，复杂的系统可以用从简单到复杂的多个模型表示。

建模的过程可以从传奇般的餐巾纸（一块白板或者裁好的一沓纸是很好的替代品）上的系统草图开始。第一个模型通常很粗略，忽略了系统的多数方面，只有设计者认为重要的少数方面，可能因为这些方面特别复杂或者是系统的关键特征。

这个粗略的模型将被细化成更加精细、更加复杂的一个或多个模型。每次迭代都从实际系统中引入更多的成分，直到所有相关的方面都引入到模型中。最终，您将达到数据模型的实现阶段，并定义系统可以管理的所有方面。

对于 XML 而言实现将一个 XML 模式，其他的选择包括 DTD、 RELAX NG 或者 WSDL（请参阅参考资料）。尽管这些实现之间存在技术上的差异，但在本系列文章中我将把它们看作是 XML 模式的变体。

业内对模型与 XML 模式之间的关系有两种不同的观点。一些作者在设计模型和 XML 模式之间划了一条清晰的界线，设计模型通常是 UML 模型或实体-关系模型，被认为是抽象的，而 XML 模式则被认为包含大量的实现细节。这种区别有助于清晰地划分建模活动与实现活动。建模通常由业务分析人员完成，而实现则是技术人员的职责。这种工作的划分模仿了典型应用程序开发中分析人员与开发人员之间的分工。

虽然我认为这种划分对编程而言是合理的，但不能保证也适用于 XML 建模——这使我倾向于对这种关系的第二种观点。XML 模式是文档的模型，您将在下一篇文章中看到，它和良好的 UML 模型在复杂程度上并没有显著的区别。毫无疑问，XML 模式包含大量的技术信息，但是描述同样多的技术信息的 UML 模型也并不少见。因此，我倾向于把 XML 模式看作是从高层模型到底层模型的模型连续统一体中的一部分。

如果安装了辅助建模工具——我将在本系列的其他文章中介绍——把模式仅仅看作是另一种模型尤其合适。

简化和图形
建模中使用的最有效的简化方式是图形。与一长串复杂指令相比，人们发现大脑更容易处理图形。多数建模方法都建立在可视化语言的基础上，如 UML、实体-关系图或者流程图。

具体到 XML 模式，用什么组成最佳的可视化语言存在两种不同的观点。一种方法是采用 XML 专用的语言，另一种则是用更一般的建模语言。XML Spy 或 TurboXML（请参阅参考资料）这类产品使用自定义的图形树表示处理 XML 模式。一种可视化呈现可能类似于图 1：

图 1. 可视化 XML 结构

为此也可以采用标准的建模语言，如 UML。图 2 是类似于图 1 的 UML 模型：

图 2. 建模 XML 的 UML

每种方法各有自己的优缺点。XML 专用的符号完全与 XML 的结构匹配，很容易标志 XML 顺序、XML 选择、元素和属性等等。也可以用简单的、自然的方式规定所有的技术信息。直到最近，许多 XML 应用程序设计者还推荐使用这种方法，因为它简单而有效。

付出的代价是建模以及工具常常不能与其他的开发工作很好地结合。虽然这种方法仍然适用于小型的 XML 项目，但是没有很好的伸缩性。这种方法也很难用于结合了 XML、Java、Web 服务和 SQL 的大型项目，因为团队中的其他人可能使用的是 UML。

有两个因素使得 UML 最适合于中型和大型的项目：

UML 应用于 Java、C++、Python、PHP、SQL、Web 服务以及差不多任何其他部属技术。它的统一性减少了培训的需要（一种语言适用于每个人），而且更容易在团队中共享设计。
UML 图可以根据需要显示更多的或较少的信息，因此可以使用同一个工具准备多种复杂层次的模型。
UML 主要的不利之处在于在处理建模的底层方面时不很友好。比如，在树中对一组元素排序很容易，但在 UML 中就需要很多技巧。

UML 和 XML
我计划在以后几篇文章中详细讨论这个话题。现在，只要指出在 XML 模式和 UML 模型之间可以建立多种映射就足够了。UML 支持多种图，包括用例图、包图、顺序图和活动图。

这里最适合的是类图，类图表示面向对象的数据模型。

图 3 是表示 person 的非常简单的 UML 模型。它包括两个类，一个代表 person 的基本数据（“person”），另一个代表 person 的“address（地址）”。矩形是表示类的符号，被分成三个部分：类名、属性以及方法。因为我们要建模的是数据而不是行为，可以忽略方法部分。

图 3. person 的 UML 模型

类之间的关系用联系表示。在模型中，联系用一条直线表示。直线可以使用连接符修饰以进行区分。比如，图 3 中的实心菱形表示这里是组合关系——换句话说，address 类的实例只能存在于 person 类的上下文中。

注意，把 UML 结构映射到 XML 可以有多种不同的选择，其中 UML 属性就是一个很好的例子。在 UML 中，属性是附加到类中的字段。在 Java 语言中只有一种合理的映射方式：属性变成一个类变量。相反，在 XML 中属性可以映射成子元素或者真正的 XML 属性。我将在以后的文章中继续讨论这个话题。

模式派生
可以尝试不同的方法绘制 UML 模型：

可以将其画在纸上或白板上。
可以使用 SmartDraw 或 Omnigraffle（请参阅参考资料）这样的向量绘图工具。
可以使用建模工具，如 IBM Rational Rose（请参阅参考资料）。
除了最简单的模型之外，您可能更愿意使用建模工具。初看起来，建模工具只不过是美化的绘图工具，但实际上提供了更多的功能。建模工具能够理解模型，因而可以为设计人员提供大量帮助。比如，在向图中增加类时，它可以自动地画出这些关系。

自动派生
如前所述，我认为 XML 模式只不过是一种详细模型的特殊呈现。因此，从 UML 模型自动派生 XML 模式是很重要的。

看着 UML 模型，将其编码成 XML 模式非常耗时而且容易出错。您可能忽略一些元素或属性，也很容易把关系搞错。所幸的是，只要在 UML 结构和 XML 模式语句间建立一对一的映射，这个过程很容易自动化。

您可以找到用于从模型自动派生模式的许多工具，其中包括：

Eclipse 建模框架（EMF），原来称为 IBM XMI Toolkit（请参阅参考资料）。EMF 包括一个代码生成器从 UML 模型派生 XML 模式。
IBM Rational Rose，它所含的脚本语言 RoseScript 可以处理 UML 模型，因而能将其保存为 XML 模式。
Velocity，来自 Apache Jakarta 的一个项目，是用于从 UML 模型生成代码的模板引擎。
hyperModel 是专门用于从 UML 生成 XML 的图形化工具。
Poseidon for UML 具有内置的代码生成功能，很容易定制为生成 XML 模式。
Codagen 是一个 UML 工具，提供了完善的代码生成功能。
本系列文章中推荐一种基于 XSLT 和 XML 元数据交换（XMI）的解决方案。XMI 是一种标准格式，可用于把 UML 模型派生 XML。它最初是为了在不同的工具之间导出/导入模型而设计的，因为这里要处理 XML，因此可以使用 XSLT 处理。

根据我的研究，由于以下原因使用 XMI 与 XSLT 非常有利：

XMI 是一种工业标准，得到所有主要建模工具的支持。任何建立在 XMI 之上的模型都可以使用这些建模工具。
XSLT 是有效表达转换的一种语言。它有很多结构使其非常适合这项任务。
所有主流平台上都可以使用 XSLT，因此选择的余地很大。
同样的技术很容易扩展到 WSDL 和其他 XML 语言。
我还有另一个标准，可能对您无关紧要。我主要从事电子商务，因此处理的模型是多家公司的协作项目。不同的公司可能采用不同的工具，因此在协作项目中不能要求在整个团队中使用一种私有产品。因为 XMI 是一种工业标准，建立在 XMI 上的解决方案可以在整个团队中很好地工作。

图 4 说明了这个过程。我编写一两个样式表从 XMI 文档（如 UML 模型）派生 XML 模式。

图 4. 派生模式

我可能还会准备一个样式表实现相反的过程：从 XML 模式到 XMI。这种样式表在处理没有使用 UML 建模的已有模式时很有用。

结束语
本文是新的系列文章的第一篇，我回顾了文档建模背后的原理，并探讨了如何在 UML 中建模 XML 模式。更重要的是，我介绍了从 UML 模型自动生成 XML 模式的工具。自动生成可以使用 XMI 与 XSLT 样式表。下一篇文章中将介绍这种样式的一个例子。

参考资料

请参与本文的讨论论坛。（您也可以单击本文上部或底部的讨论来访问论坛。）

阅读 Cameron Laird 的 XMI 入门文章，“XMI 与 UML 合力推动产品开发”（developerWorks，2001 年 10 月）。

看一看 Donald Bell 的“UML 基础：统一建模语言简介”（developerWorks，2003 年 6 月），这是一篇浅显易懂的 UML 文章。

请访问 DocBook.org，这是 DocBook 的资源站。DocBook 是一种图书出版的常见词汇表，读一读您就知道图书实际上是多么复杂的一个系统。

进一步了解 RELAX NG，有人建议用它来代替 XML 模式。它有一些有趣的特性，在市场上得到了广泛的认可。如果您使用它，请阅读 Nicholas Chase 的教程“理解 RELAX NG”（developerWorks，2003 年 12 月）。

使用 WSDL 描述 Web 服务。

看一看 XML Spy 和 TurboXML，这是两种使用专门可视化语言的 XML 模式编辑器。

研究 SmartDraw 和 Omnigraffle，这两种绘图工具有时候用于绘制简单的 UML 模型。虽然适用于小型项目，但不支持 XMI 而且不够灵活。

探索模板驱动的 Jakarta Velocity 和 Asbot 代码生成器。

使用 Eclipse Modeling Framework 和 hyperModel 从 UML 模型生成代码（包括 XML 模式）。

考察 Poseidon for UML 和 Codagen，具有代码生成功能的 UML 建模工具。

探索 IBM Rational Rose，领先的 UML 建模产品。您可以在 developerWorks 的 Rational 栏目找到大量的 Rational 和 UML 资源。

在 developerWorks XML 技术专区可以找到更多的 XML 资源，包括 Benoit Marchal 使用 XML 专栏以前的所有文章。

了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。

关于作者
Benoit Marchal 是一位比利时籍顾问。他是 XML by Example, Second Edition 以及其他几本 XML 书籍的作者。您可以通过 bmarchal@pineapplesoft.com 或者他的个人站点 www.marchal.com 和他联系。