本专栏当前的话题是建模、UML 和 XML。具体而言,即研究 UML 建模在 XML 开发中的应用,特别是如何用 XSLT 样式表实现自动派生。
随 着 XML 成为开发项目的一种常见特性,很多开发人员对把 XML 和开发过程中的其他部分结合起来越来越感兴趣。尽管许多组织仍然依靠专门的工具进行 XML 开发,但大的趋势是在 XML 的开发中采用其他开发需求已经使用的方法论,或者至少是一组通用的工具,比如 Java 技术、数据库和 Web。
上一期已经指出,模型是帮助计算和预测的系统简化描述。在本文的环境中,所谓系统指的都是 XML 词汇表。
图 1 表示的是模型连续体(continuum)的建模过程。第一个模型是画在白板(或者一沓纸)上的,一般不那么正规。这个阶段的目标是让所有的参与者(用户、开发人员和设计人员)有机会自由地表达自己的观点。
图 1. 模型连续体下一步是绘制一个 UML 模型(如果词汇表很复杂可能要画多个模型)。UML 模型更加精确和形式化,但仍然是综合性的和可阅读的,因为其主要目的是作为小组成员之间的交流工具。
最后一个模型是 XML 模式,这是最精确的模型。它的目标是使解析器能够针对词汇表的定义验证 XML 文档,因此在保持可读性的同时更强调精确性。
这些模型之间的主要区别在于目标不同:从非正式的交流到通过解析器进行精确的、形式化的验证。区别 不在于模型的性质(XML 词汇表的简化描述),而在于模型提供的帮助层次。
既然把模型看作是从最不准确到最形式化的连续体,探讨模型的 自动派生就合情合理了,即从早期模型自动生成新的模型的过程。显然,只有当两个模型具有等同的描述性时才能很好地自动派生,这和一些模型比另一些更富于描述性的观点有几分冲突。如何解决模型中的不同描述层次将在下一期讨论,现在讨论的重点是派生。
您也许还能记得上一期文章中,我通过 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.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 继承的属性。
|
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"?> |
要注意, 清单 1中的 XML 元素和属性是如何与 图 2中的类和属性匹配的。您现在又回到了原地:XMI 文档是 UML 元模型的直接表示,因为 UML 元模型是 UML 本身的描述。
UML 元模型的一部分处理概念的可视化表示--把概念画到屏幕的何处。由于两方面的原因我的样式表中没有处理这些信息:
- 从 UML 模型派生出 XML 模式不需要这些信息。
- 从 XML 模式派生 UML 模型时生成可视化的输出非常困难。更合理的选择是用建模工具打开模型,花几分钟准备模型在屏幕上的可视化表示。最困难的工作(正确的定义)已经由样式表完成了。
现在您已经掌握了阅读 XMI 文件的要点,很容易就能把 XMI 标签映射成等价的 XML 模式。一种可能的映射是:
-
UML:Model
变成xs:schema
;目标名称空间从模型名导出。 -
UML:Class
变成全局 XML 元素声明(xs:element
)。 -
UML:Attribute
变成本地 XML 元素声明(xs:element
)。
清单 2 是实现这种映射的 XSLT 样式表:
清单 2. XML 模式派生 <?xml version="1.0"?> |
显然, 清单 2中 的样式表功能非常有限(只进行了很少的错误检查),因为它仅仅支持 UML 元模型很小的一个子集。它没有考虑包、接口、关联等等。只需要对上面描述的过程稍加扩展,就可以进一步完善这个样式表以支持上述概念:研究 UML 元模型中相应的部分、定义到 XML 模式的映射然后实现它。
如果遵循常规的建模流程,很容易得到 清单 2。您经常会发现已经存在一个 XML 模式,可以作为工作的起点。重新建立 UML 模型太麻烦了,如果由一个样式表实现逆映射会非常方便。清单 3 是一个例子:
<?xml version="1.0"?> |
如果要说本文中介绍的样式表很简单,就太过谨慎了。这些例子一般不到 50 行,只能处理 UML 元模型的一个子集。实际的样式表能够识别多得多的 UML 概念,通常需要 500 行甚至更多。本期文章的目标是介绍自动化模型派生背后的概念:
- 这些模型(UML、XML 模式)都用一个数据集表示,这种特殊的数据集称为元模型。
- 可以建立 UML 元模型和 XML 模式之间的映射。
- 可以通过 XSLT 样式表实现这种映射。
- UML 和 XML 模式仅仅是同一事实的不同表示,区别在于服务于不同的目标。
本文中,我不得不作一些简化。如果您尝试扩展 清单 2和 清单 3中的样式表,可能会遇到两个问题:
- UML 模型可能不够具体(因为是一种高级视图),无法派生出有意义的 XML 模式(低级的、详细的模型)。
- UML 元模型和 XML 模式之间可能存在多种合理的映射。
如何解决这两个问题在后面两期文章中讨论。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- 请参与本文的 讨论论坛。(您也可以单击本文顶端或下端的 讨论来访问论坛。)
- 在对象管理组织(OMG)的网站上阅读 UML 规范,其中包括完整的 UML 元模型。
- 同样在 OMG 网站上可以找到 XMI 规范,其中包括一些 UML 数据的样例。虽然没有完全支持这些例子的工具,但可以作为一个很好的起点,很容易针对各种工具的特点进行调整。
- 回顾本专栏的上一期文章“ UML, XMI, and code generation, Part 1”( developerWorks,2004 年 3 月),那篇文章中 Benoit Marchal 讨论了 UML 和 XML 模式的关系。
- 如果不熟悉 XML 模式,教程“ XML Schema Infoset Model”( developerWorks,2004 年 11 月)可以帮助您快速入门。
- 研究 IBM Rational Rose,一流的 UML 建模产品。在 developerWorks 的 Rational 栏目中可以找到大量关于 Rational 和 UML 的资源。
- 在 developerWorks XML 专区 可以找到数百篇 XML 资源,包括 Benoit Marchal 使用 XML 专栏以前的各期文章。
- 了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。