在 使用 XML专栏的前两期文章中，我讨论了建模，更具体地说是在 XML 应用程序开发中使用 UML 建模。建模是 XML 开发中一个重要的方面。不管怎么说，XML 是一种结构化语言，因此构成和组织信息就是 XML 存在的目的。这几篇文章重点讨论如何把 XML专用的建模语言与软件开发的行业标准 UML 结合起来。
建模的不同形式谈到建模，前两篇文章中我已经用了很大的篇幅介绍了我的观点：简而言之，我相信最合理的策略是把建模看作是一种连续的活动，从白板前的公开讨论（或者小型办公室中的一沓纸）开始，直到生产出 W3C XML Schema 或者 WSDL 文件结束。
每一步中模型都进一步精化，更加形式化。要记住，模型是系统的简化表示，创建它是为了帮助理解系统，随着对系统的理解不断深入，模型变得越来越完整是合乎逻辑的。
因此，我相信使用工具支持您的建模活动是至关重要的 —— 那些能够帮助您精化模型的工具。我曾经见证过几个因为建模失败而陷入泥潭的项目，共同的一点就是缺乏建模和开发活动之间的集成。所幸的是，解决方法很简单，只需要部署工具来集成这两类活动。
理想的情况是模型中的所有变动都立刻反映到实现中，但实现这种理想情况基本上是不可能的。比如，Java 代码生成程序可以生成或者更新主干实现，但是它们不可能改变算法。有了 XML，就可以实现这种理想化的情况了，因为处理的总是数据模型。尽管使用不同的语言，提供的详略程度一般也不相同，但是 UML 模型和 XML Schema 都是数据模型。
样式表、 XMI 和 XML Schema中介绍了两个样式表：第一个样式表把保存在 XMI 文件中的 UML 模型转化成 XML Schema；第二个样式表执行相反的操作，从 XML Schema 生成 XMI 文件。
转换依赖于 UML 元模型（保存 UML 模型的数据模型）到 XML Schema 的映射。每个 UML 概念（类、属性、关联，等等）都在 UML 元模型中表示，因此如果规定 UML 类表示成 XML 元素，样式表只需要把 XMI 中的 UML:Class 转化成 XML Schema 中的 xs:element 。
简单的样式表可以自动完成用 XML Schema 实现 UML 模型的繁杂过程，但是为了适应本文的篇幅，我作了大量的简化。
注意，虽然讨论以从 UML 模型到 XML Schema 的转换为主，逆向转换也很有用。比如，可能需要在项目中包含其他团队或者公司开发的只提供 XML Schema 的元素。
更强大的样式表这里重新回顾 中的样式表，并尝试解决当时提出的两个问题中的一个：UML 模型中缺少实现信息。造成这个问题的原因有二：
- UML 是一种通用语言，因此虽然支持很多建模概念，但是缺乏针对 XML 的一些概念。比方说，XML 有元素的顺序序列，而 UML 没有对概念排序。
- XML 是一种层次化的数据模型，而 UML 使用更加灵活的图。因此，UML 和 XML 间有可能存在多种合法的映射，您必须告诉样式表要采用哪一种。
扩展 UML从一开始，UML 的设计者就认识到 UML 可能会被用于没有预料到的用途，因此实现了扩展机制，以允许用户改进 UML。
这些扩展机制之一是 构造型（stereotype），目的是允许用户在 UML 中定义新的概念，以精化已有的概念。使用构造型，用户基本上可以对这种建模工具说“我有一个概念与类（或者对象、参与者、关联，等等）相似，但是更加具体。”
从实践的角度看，构造型是元模型中的一种继承形式。这样有助于把构造型看作是一个 UML 概念的后代。
事实上，如果读过 UML 规范，您就会看到标准本身也大量地使用构造型。比如：
- 注释有需求（requirement）和职责（responsibility）的构造型。
- 约束有不变式（invariant）、前件（precondition）、后件（postcondition）和 stateInvariant 等的构造型。
当然这些都不是用户定义的构造型。
从图形上看，构造型用包围在尖括号中的关键字表示，比如图 1 中的 <<requirement>> 。注意，UML 允许用户重新定义构造型的图标，但是很少有工具支持这一特性。
图 1. UML 中的构造型 与构造型密切相关的第二种扩展机制是 标记（tag）。构造型允许用户定义新的 UML 概念，而标记则允许用户存储关于这些新概念的信息。构造型提供了元模型级的继承，而标记在元模型级提供了向构造型增加类属性信息的机制。
用于 XML 的构造型我首先说明如何规定一个层次结构。您将定义一个构造型 root，用于标记 XML 层次中作为根的元素。您将用这个构造型标记一个或多个类，样式表把它们作为全局元素实现。（在 XML Schema 中只有全局元素才能是根。）
注意，可以有多个元素标记为根，这与 XML Schema 语言是一致的。还请注意，我决定把这个构造型称为“root”而不是"global“（全局元素）。UML 和 XML 之间可能存在不同的映射：比如，您可以在 Schema 中把所有的元素标记为全局性的以便使其能够在其他 Schema 中重用，也可以把尽量多的元素声明为本地的。（事实上使用全局元素和本地元素背后有一套非常复杂的理论，请参阅 。）
我认为这些实现决策不应该在 UML 模型中公开。一个理由是，这样做在修改实现规则时不需要重新访问 UML 模型。事实上，如果把元素标记为“全局的”而又决定改变实现规则，比方说把所有的元素公开为全局的，就需要重新查看整个模型并修改多数构造型。我不愿意在 UML 模型中公开过多的实现细节。我准备在下一篇文章中更详细地讨论这个问题。
所处理的词汇表也会影响到把哪些公开为构造型。比如，如果指定用于出版或者文档应用程序的词汇表，您可能希望定义一个属性构造型。在处理数据存储的词汇表时，对映射成属性还是元素，采用固定的规则可能更合理一些（比如本文中的样式表把一切都映射成 XML 元素）。
用于 XML 的标记类似的，我还定义了 position 标记，用于指定元素在 XML 序列中出现的顺序。这里的问题是模式中的元素顺序在转换成另一个模式时不一定改变。这在处理关联时尤其明显：UML 工具不对关联排序，因此不能依靠这些工具按照一定的顺序输出关联。
一种方法是按照名称排序关联，另一种方法是使用标记明确控制位置。我发现后一种解决方案通常更好一些。
样式表实现图 2 是一个 UML 模型，它定义了三个类（ person 、 address 和 job ）以及彼此之间的关联。该模型是上一篇文章所介绍的模型的扩展。
图 2. UML 模型 - 构造型和标记在 XMI 文件的一开始定义然后被引用，因此声明两个变量用于保存它们的 ID 非常方便。
- 模型模板选择带有 root 构造型的类声明为全局元素，其他的类声明为本地元素。如果愿意，可以改变这一规则，把所有的元素声明为全局的。
- 类模板遍历关联并使用 position 标记对其排序。
- 关联模板使用特殊的模式遍历关联右端连接的类。这种模式定义了两个模板：第一个用于带有 root 构造型的类，插入对类的引用；第二个用于一般类，作为本地元素插入类定义。
这里不再给出从 XML Schema 转化成 XMI 的样式表，留给读者作为练习。
结束语通过到目前为止所介绍的内容，您应该已经能够自己编写样式表把任何 UML 模型转化成 XML Schemas 了。我相信，一旦掌握了这门技术，您就会发现 UML 建模是设计 XML Schema 最简单的方法之一。
虽然这里介绍的样式表仅限于 UML 元模型的一个子集，但是为设计更加强大的模型提供了一个很好的起点。
下一篇文章将介绍如何解决最后一个遗留问题：存在 UML 到 XML 的多种映射时如何设计样式表。 |
