使用 XML: UML、XMI 和代码生成，第 4 部分

本文是关于使用工业标准 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 中的三种模型：

图 1. 三种 UML 模型

按 照逆时针的顺序，第一个模型（左上角）是用构造型标记元素。第二个模型（下方）用 UML 属性表示 XML 属性，并把 XML 元素建模为联系（不同的 UML 概念标记 XML 中的差异）。最后一个模型（右上角）没有做这么详细的区分。哪个模型最清楚？要知道，这是一个非常简单的模型。设想如果每个用例中有数十个类，哪一种模型 更容易阅读呢？打印出来哪一个用的纸张最少呢？显然最后一个模型可读性最好。

将 UML 图看作用户界面是合理的。只要可能，就应该减少混乱，用明确可读的方式对信息编码。

显然，如果要从 UML 模型中提取信息，应该能在其他某个地方使用。这就是 XSLT 样式表所起的作用：不仅要在 UML 和 XML 之间转换，还必须事先保证转换有效进行的规则。前面的文章中所介绍的样式表都遵循下面这些原则：

• 从不创建 XML 属性。大小可能不同，但是元素可以编码此类项目的所有信息。
• 将 UML 类映射为全局元素，将 UML 属性映射为本地元素。这样做主要是为了避免名称冲突：如果两个类具有相同的属性，映射为全局名可能会造成冲突。

这两条简单的规则足以将模型中省略的所有信息加上。另外一个好处是，如果我决定改变这些规则（比方说不再使用本地元素），那么需要改变的只有样式表，而不必改变模型。如果这些细节写入模型，那么模型也需要更新。

但不能过于简化

您可能不同意我对属性所持的观点。虽然属性在这个特定的应用程序中不重要，但是您的应用程序可能不同。不同的项目强调 XML 语法的不同方面：

• 电子商务项目往往强调类的结构，不太关注具体的 XML 语法。
• 工业组织往往在类层次结构方面大量投资，努力实现标记的重用（在不同的上下文中重用元素）。
• 和实际数据相比，商务人员往往更关心业务流程。
• 出版项目往往担心硬编码 XML 标记的易用性，因为作者可能需要手工编写 XML 文档。

因此如果属性对您的项目至关重要，则将其在模型中表示出来。同样要把 UML 图看作是 XML 词汇表的界面，当然不希望 UI 隐藏重要的方面。模型只是一种工具，没有必须显示什么不显示什么的硬性规定。要做的就是捕获应用程序需要的所有信息，如此而已。

可以看出，我不赞成某一种标准映射适用于所有 XML 应用程序的说法。XML 应用程序千差万别，不可想像有一种映射到处都适用。

显然，XML 的 UML 表示中有 95% 对所有项目都是通用的，您可以使用我提供的那些样式表作为一个很好的起点。这种情况和 SQL 代码生成类似，常常需要微调数据库的代码生成。

一点忠告

为了最大限度地适应项目需要，虽然我鼓励调整 UML 到 XML 的映射，但是最好在 UML 框架之内调整，没有必要脱离标准的 UML。

这里有一个例子。图 2 是我经常看到的一个模型，但这种做法是不好的。具体而言，问题出在 make-element 和 namespace-uri 属性。

图 2. 糟糕的建模方法

推想起来，地址并没有 make-element 属性，该属性只不过是暗示样式表生成给定的语法。这个属性表示的信息和地址无关，编码的是地址的 XML 编码信息。这样做既危险，又毫无意义。

危险是因为歪曲了 UML 属性的定义。属性应该提供它自己的类的信息，而不是 XML 语法的信息。这样的模型无法移植，读者难以理解，而且可能造成严重的维护问题。

此 外，这样做也毫无意义，因为 UML 提供了扩展机制（构造型和标签）来应付这类要求。如果需要标识特定类型的类或者增加类的元数据层信息，就必须使用 UML 扩展。再说一次，为了最大限度地适应项目需要，虽然我鼓励对 UML 到 XML 的映射进行调整，但强烈建议以标准方式进行调整。

回页首

结束语

我 相信本系列文章使您对 XML 应用程序的 UML 建模有了更深的理解。使用 UML 建模 XML 应用程序已经越来越引起人们的兴趣，仅仅因为 UML 模型可以在 Java、C++ 和其他语言之间共享。我已经分析了支持对 XML 应用程序建模的工具（UML 元模型、XMI 和 XSLT）。使用适当的建模工具，再加上我提供的样式表，就可以开始了。

如果您对本系列文章有什么建议或者问题，请参与论坛中的讨论（请参阅 参考资料）。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 回顾 Benoît Marchal 撰写的本系列文章的以前各期：
  • 第 1 部分讨论了 UML 和 XML 模式之间的关系（ developerWorks，2004 年 3 月）。
  • 第 2 部分介绍了 UML 元模型和 XMI，后者是基于 XML 的模型交换规范。作者然后探讨了如何从元模型映射到 XML Schema（ developerWorks，2004 年 5 月）。
  • 第 3 部分探讨了扩展 UML 语言的工具：构造型和标签（ developerWorks，2004 年 6 月）。
  
  
• 完整的 UML 元模型，请参阅对象管理组织（OMG）站点上的 UML 规范。
  
  
• 探索 IBM Rational Rose，这是一种领先的 UML 建模产品。在 developerWorks的 Rational专区可以找到大量 Rational 和 UML 资源。
  
  
• 通过 ArgoUML和 Poseidon for UML (Community Edition)研究本系列文章中介绍的技术，这两种免费建模工具都可导出 XMI，虽然和 IBM Rational Rose 相比局限性较大。
  
  
• 阅读 Mike Padilla 撰写的“ Strike a balance: Users' expertise on interface design”（ developerWorks，2003 年 9 月），它提供了用户界面设计方面的建议，我认为大多数都适用于 UML 和 XML 之间的映射。在可选择的建模工具范围之内，您也许会希望尽量简化手头的任务。
  
  
• 研读 Alan Cooper 所著的 The Inmates Are Running The Asylum 一书，这是关于用户界面的最佳图书之一，也是最棒的计算机科学图书之一。
  
  
• 在 developerWorksXML 专区 可以找到数百篇 XML 资源，其中包括 Benoît Marchal 使用 XML 专栏以前各期的文章。
  
  
• 在 developerWorks Developer Bookstore可以找到各种关于 XML 的书籍，其中包括 Benoît Marchal 所著的 XML by Example 。
  
  
• 了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。

原文http://www.ibm.com/developerworks/cn/xml/x-wxxm26/index.html