本文是关于使用工业标准 UML 对 XML 应用程序建模的系列文章的最后一篇。上一期（请参阅 ）留下了一个问题：如果 UML 模型和 XML 词汇表之间存在多种可能的关系怎么办？本文进一步升华了贯穿本系列文章的一个主题：建模是出于特定目的而对现实的简化。
您 已经看到，我提倡根据项目需要采用实用灵活的方法。本文将讨论还没有解决的几个问题，以便帮助将这些技术应用于您的环境。通过目前介绍的样式表例子，只要 再有一个建模工具（如 IBM® Rational Rose®），就可以很容易地采用与业界兼容的方式对 XML 项目进行建模。
前面几期文章曾多次提到，模型不是凭空而来的，建立模型是为了服务于特定的目的。模型是现实的某些方面的简化表示，通过这种简化分析其背后的现实就更容易了，从而最终能够更好地理解它。
对 于本系列文章而言，现实就是 XML 词汇表或者 Web 服务。不可否认，这些本身已经就是抽象的现实了。但如果您曾经阅读过 XML 模式文本，很快就会明白为何需要简化了。（有些绕弯子的）模式语法造成的纷乱迫切需要进行简化。UML 最明显的好处之一是，作为一种图形化的语言比标记更容易阅读。另一个好处是 UML 提供了更具综合性的视图，只要看一眼模型就能大致了解类的数量及其相互关系的复杂程度。无论如何，UML 省略了很多底层的综合细节，如名称空间前缀、本地元素和全局元素，以及一个概念是元素还是属性。
理想情况下，建模可以帮助更好地理解应用程序，从而创造出更加适用的 XML 词汇表或者设计更加强大的 Web 服务 API。
简 化到何种程度才算适当呢，这与应用程序的特殊性以及精化模型的方式有关。前面已经提到，建模不是一蹴而就的事（除了那些最简单的应用程序）。 一般来说，建模从一次非正式的会话开始，期间可以收集到模型中基本的定义和最简单的关系。然后要经过一系列的评审会议对模型进行精化。通过不断的迭代逐渐 形成更加正式、更加完整的模型（一般要从白板上转移到建模工具中）。最后，UML 模型转化成 XML 模式，这是 XML 词汇表非常正式的描述。或者模型被处理成 WSDL 文件，同样是 Web 服务的正式描述。也可用同样的模型生成 Java 类。
看一看最后一个阶段：UML 模型被处理成更加精确的 XML 模式。您已经看到，如果按照一种非常简单的方法，这一步令人吃惊地容易。很多 UML 建模工具（如 IBM Rational Rose）按照 UML 元模型的定义来存储模型。
简而言之，UML 元模型就是表示 UML 模型的一组类。从注释到包，包括类本身，UML 中的每个概念都有一个元类。对象管理组（Object Management Group，OMG）已经标准化了 XML Metadata Interchange (XMI)元模型的 XML 表示。 XMI 允许 XML 开发人员访问模型。事实上，我应该说“一定程度上的标准化”，因为不同的建模工具（甚至同一工具的不同版本）可以按照不同的方式解释 XMI。在实践中，这种差别非常细微，可以在样式表中解决。
不 管怎样，要从 UML 模型生成 XML 模式，只要确定 UML 元模型中的哪个概念和哪个 XML 模式标签对应就可以了。比如，显然 UML 类应该转化为 XML 元素。因为 UML 元模型保存在 XML 中，生成模式就只需要编写一个 XSLT 模板，让其匹配所有的 UML:Class 实例，并将其转化为 xs:element 。
实现 逆向样 式表从 XML 模式生成 UML 模型也是可能的（并且常常是人们所期望的）。如果需要把标准词汇表结合到您的设计中，这种技术非常方便。 这种词汇表很少以 UML 的形式提供，通常是 XML 模式。只要有适当的样式表，对其进行逆向工程转化成模型用不了多少时间。
编写与 XMI 元素相匹配并将其转化为 XML 模式元素的样式表，从概念上讲很简单。我在以前的文章中给出的样式表既不是很长也不是特别复杂。
至少理论上是这样。在实践中如果不够谨慎的话，情况也可能失控。首先，XSLT 编码可能非常棘手（虽然不会出现重大的变化）。回顾一下 文章中介绍的样式表，特别要注意 UML:Class 的模板。这个模板远远比不上我写过的那些最复杂的 XSLT 模板，但也不像上面所说的那样简单。因此在尝试解决这个项目之前一定要磨练您的 XSLT 技巧（或者打开我的样式表看看）。
其 次，更为重要的是，确定哪个 UML 概念与哪个 XML 概念相匹配也不一定很简单。上一期文章中曾经指出，构造型和标签可以作为扩展 UML 模型的工具，以便支持在 UML 中没有等价物的 XML 概念。构造型和标签都很有用，如果您对通过构造型和标签 XML 模式的每个方面感兴趣，请坚持下去吧！
要记住，按照定义模型是一种简化，因此模型（即使是精化的模型）不包括所有的实现细节是完全合理的。很多方面最好放在模型之外，留在样式表本身中。
W3C XML Schema Recommendation 非常复杂，可能不需要考虑它的每一个细节，因此，确定所需的一组特性子集是合算的，它将用于给定项目。不要为推荐标准中的其他内容浪费时间。
应该包含什么，不包含什么？不幸的是，对于这个问题我没有特定的答案。最好的经验是 包含那些对于项目很重要的方面而忽略其他方面。当然，这就留下了一个问题，即确定什么对于您的项目是重要的。
对于多数应用程序而言，都希望隐藏全局元素和本地元素以及元素和属性之间的区别。实际上，更重要的是定义必要的数据字段，而不是决定这些字段作为元素还是属性。不管怎么样，元素和数据都是存储数据的字段。
虽然存在例外情况，元素和属性之间的差别通常是实现上的细节，对于设计者而言，在很大程度上是无关的细枝末节。因此，虽然使用不同的 UML 概念（可能还包括构造型）来建模元素和属性可能很有吸引力，但我不建议这样做。
为何要忽略元数和属性之间的差别呢？因为它搞乱了模型，只增加了很少的有用信息。比较图 1 中的三种模型：
