[1.2]由UML模型通过XMI生成XML,通过XSLT展示到表现层

本专栏当前的话题是建模、UML 和 XML。具体而言，即研究 UML 建模在 XML 开发中的应用，特别是如何用 XSLT 样式表实现自动派生。

随着 XML 成为开发项目的一种常见特性，很多开发人员对把 XML 和开发过程中的其他部分结合起来越来越感兴趣。尽管许多组织仍然依靠专门的工具进行 XML 开发，但大的趋势是在 XML 的开发中采用其他开发需求已经使用的方法论，或者至少是一组通用的工具，比如 Java 技术、数据库和 Web。

自动派生
 上一期已经指出，模型是帮助计算和预测的系统简化描述。在本文的环境中，所谓系统指的都是 XML 词汇表。

图 1 表示的是模型连续体（continuum）的建模过程。第一个模型是画在白板（或者一沓纸）上的，一般不那么正规。这个阶段的目标是让所有的参与者（用户、开发人员和设计人员）有机会自由地表达自己的观点。

图 1. 模型连续体

下一步是绘制一个 UML 模型（如果词汇表很复杂可能要画多个模型）。UML 模型更加精确和形式化，但仍然是综合性的和可阅读的，因为其主要目的是作为小组成员之间的交流工具。

最后一个模型是 XML 模式，这是最精确的模型。它的目标是使解析器能够针对词汇表的定义验证 XML 文档，因此在保持可读性的同时更强调精确性。

这些模型之间的主要区别在于目标不同：从非正式的交流到通过解析器进行精确的、形式化的验证。区别不在于模型的性质（XML 词汇表的简化描述），而在于模型提供的帮助层次。

既然把模型看作是从最不准确到最形式化的连续体，探讨模型的自动派生就合情合理了，即从早期模型自动生成新的模型的过程。显然，只有当两个模型具有等同的描述性时才能很好地自动派生，这和一些模型比另一些更富于描述性的观点有几分冲突。如何解决模型中的不同描述层次将在下一期讨论，现在讨论的重点是派生。

XML 元数据交换（XMI）
您也许还能记得上一期文章中，我通过 XMI 和 XSLT 实现了自动派生。假设您熟悉 XML 模式（否则请参阅参考资料），我们用这一节来介绍 XML 元数据交换（XML Metadata Interchange，XMI）。

词汇表和兼容性
XMI 是一个非常复杂的规范（1.2 版有 400 多页），本文基于实现自动派生的需要做尽可能简单的介绍。

XMI 并没有规定一种 XML 词汇表，而是定义了从元模型生成词汇表的一种算法。换句话说，XMI 没有定义 Class、Attribute、Association 或者其他您期望看到的标签。相反，XMI 规定了如何为元模型中的概念创建标签。当然这需要处理大量的模型，先暂时忍耐一下——您很快就会明白。

因此，与其说是词汇表，XMI 更像是一个框架。不幸的是，这意味着不同的工具会以不同的方式解释这个框架。即使同一种工具的不同版本也有差别：Rational Rose 最初通过 Unisys 开发的一个插件支持 XMI。最新版本的 Rational XDE 提供了 XMI 的内在支持，但却是一个略有不同的变体。差别尽管不一定很大，但也可能造成不兼容。在实践中，合理的做法是针对社区中使用的一两种工具设计样式表，而不必顾及其他的工具。

本文中没有采用特定的 XMI 版本，而是选择采用 OMG 发表的例子。虽然没有直接支持这些例子的工具，但作为很好的起点，针对选用的工具进行适当调整并不困难。

XMI 头
虽然 XMI 主要是规定了一种算法，但是也定义了少量的标签和属性。将要用到的包括：

XMI 一定是根元素。它必须包括 xmi.version 属性（合法的版本有 1.0、1.1、1.2 和 2.0）。
XMI.header 用于存放关于模型的信息。最重要的子元素有 XMI.documentation 和 XMI.metamodel。
XMI.documentation 保存最终用户的信息，其子元素有（这些子元素的名字含义非常明显）：
- XMI.owner
- XMI.contact
- XMI.longDescription
- XMI.shortDescription
- XMI.exporter
- XMI.exporterVersion
- XMI.exporterID
- XMI.notice
XMI.metamodel 记录应用 XMI 算法的元模型——在这里即 UML 元模型（XMI 也用于其他元模型，如同样由 OMG 发布的 Metaobject Facility，MOF）
XMI.content 包含实际的模型。
xmi.id 和 xmi.idref 是用于链接的属性：xmi.id 是一个元素标识符，必须是唯一的；xmi.idref 是通过标识符对元素的因素的引用。

元模型
UML 元模型是描述 UML 语言的模型——具体而言，它描述类、属性、关联、包、协作、用况、参与者、消息、状态和 UML 语言中所有其他概念。为了保持一致性，元模型使用 UML 编写。

前缀“meta”表明元模型（metamodel）描述的是模型的模型。类似地，XML 是一种元语言，因为它是一种描述语言的语言。

UML 元模型在 UML 规范中发布。具体而言，XMI 使用 UML 规范（请参阅参考资料）第5章中所描述的“UML Model Interchange”。

要注意，UML 元模型庞大得吓人。本文中只能简略地提一提。图 2 摘自描述类的元模型，类是类图中的核心概念。

图 2. 类的元模型

这个元模型中，类的概念用元类 Class 建模，后者继承自抽象元类 Classifier。Classifier 是 Class、Interface 和 Datatype 的祖先（后两者没有在图 2 中表示出来）。继承链再往上推：GeneralizableElement 代表所有可以泛化（被继承）的概念；ModelElement 代表模型中的所有抽象（如名称空间、约束和类）；最后是 Element，最高层次的元类。这些元类都有 Class 继承的属性。

XMI 的变体
少数供应商描述了他们的 XMI 变体。根本的办法是建立一个小模型然后导出，在用文本编辑器打开文件查看。

XMI 元素和属性（XMI.header、XMI.content 或 xmi.id）就像是文件中路标。

观察元模型中的主要元素（如 Class、Attribute、Association），看看它们是如何映射到 XML 中的。如果手头上有元模型的片段会非常方便。

区别只是表面性的：似乎没有两个应用程序使用同样的名称空间。一些应用程序使用 XML 元素编码元模型中的属性，而另一些则使用属性（如清单 1 所示）。实际上，通过比较元模型很容易就看出其中的区别。

Classifier 和 Feature 之间存在组合，后者是 StructuralFeature 的祖先。Attribute 派生自 StructuralFeature。

这个元模型令您感到迷惑吗？尝试忘掉它是一个元模型，一个关于 UML 的元模型，把它看作是一个普通的模型吧。图 2 简单地指出了 Class 的概念，这是一种和接口以及数据类型有关（通过从 Classifier 继承）的高度专业化的元素。Class 拥有名称、可见性以及其他许多性质。最后，Class 和 Attribute 之间存在关联。

因此，图 2 形式化地表示一个类可以有名称、可见性和其他特性，还可以具有属性。事实上，图 2 是 UML 类的定义。如果您觉得迷惑，可能是因为这个定义本身是用 UML 编写的！

为了简单起见，我在图 1 中有意省略了名称空间、约束、原型、继承以及使类之所以成为类的其他因素。请相信我，这些都包括在完整的 UML 元模型中，但是对本文而言没有用处。

何必为元模型费心呢？因为在交给 XMI 算法时您得到的是 UML 的 XML 词汇表。作为一个例子，清单 1 是图 3 的一种 XMI 表示（应用规范中所示范的 XMI 变体，参见前述）：

图 3. 地址的 UML 模型

清单 1. 导出到 XMI 的地址

<?xml version="1.0"?>

<XMI.header>

<XMI.documentation>

<XMI.exporter>ananas.org stylesheet</XMI.exporter>

</XMI.documentation>

<XMI.metamodel xmi.name="UML" xmi.version="1.4"/>

</XMI.header>

<XMI.content>

<UML:Model xmi.id="M.1" name="address" visibility="public"

isSpecification="false" isRoot="false"

isLeaf="false" isAbstract="false">

<UML:Namespace.ownedElement>

<UML:Class xmi.id="C.1" name="address" visibility="public"

isSpecification="false" namespace="M.1" isRoot="true"

isLeaf="true" isAbstract="false" isActive="false">

<UML:Classifier.feature>

<UML:Attribute xmi.id="A.1" name="name" visibility="private"