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

在 使用 XML专栏的前两期文章中&＃xff0c;我讨论了建模&＃xff0c;更具体地说是在 XML 应用程序开发中使用 UML 建模。建模是 XML 开发中一个重要的方面。不管怎么说&＃xff0c;XML 是一种结构化语言&＃xff0c;因此构成和组织信息就是 XML 存在的目的。这几篇文章重点讨论如何把 XML专用的建模语言与软件开发的行业标准 UML 结合起来。

建模的不同形式

谈到建模&＃xff0c;前两篇文章中我已经用了很大的篇幅介绍了我的观点&＃xff1a;简而言之&＃xff0c;我相信最合理的策略是把建模看作是一种连续的活动&＃xff0c;从白板前的公开讨论&＃xff08;或者小型办公室中的一沓纸&＃xff09;开始&＃xff0c;直到生产出 W3C XML Schema 或者 WSDL 文件结束。

每一步中模型都进一步精化&＃xff0c;更加形式化。要记住&＃xff0c;模型是系统的简化表示&＃xff0c;创建它是为了帮助理解系统&＃xff0c;随着对系统的理解不断深入&＃xff0c;模型变得越来越完整是合乎逻辑的。

因此&＃xff0c;我相信使用工具支持您的建模活动是至关重要的 —— 那些能够帮助您精化模型的工具。我曾经见证过几个因为建模失败而陷入泥潭的项目&＃xff0c;共同的一点就是缺乏建模和开发活动之间的集成。所幸的是&＃xff0c;解决方法很简单&＃xff0c;只需要部署工具来集成这两类活动。

理 想的情况是模型中的所有变动都立刻反映到实现中&＃xff0c;但实现这种理想情况基本上是不可能的。比如&＃xff0c;Java 代码生成程序可以生成或者更新主干实现&＃xff0c;但是它们不可能改变算法。有了 XML&＃xff0c;就可以实现这种理想化的情况了&＃xff0c;因为处理的总是数据模型。尽管使用不同的语言&＃xff0c;提供的详略程度一般也不相同&＃xff0c;但是 UML 模型和 XML Schema 都是数据模型。

样式表、 XMI 和 XML Schema

上一篇文章中介绍了两个样式表&＃xff1a;第一个样式表把保存在 XMI 文件中的 UML 模型转化成 XML Schema&＃xff1b;第二个样式表执行相反的操作&＃xff0c;从 XML Schema 生成 XMI 文件。

转换依赖于 UML 元模型&＃xff08;保存 UML 模型的数据模型&＃xff09;到 XML Schema 的映射。每个 UML 概念&＃xff08;类、属性、关联&＃xff0c;等等&＃xff09;都在 UML 元模型中表示&＃xff0c;因此如果规定 UML 类表示成 XML 元素&＃xff0c;样式表只需要把 XMI 中的 UML:Class 转化成 XML Schema 中的 xs:element 。

简单的样式表可以自动完成用 XML Schema 实现 UML 模型的繁杂过程&＃xff0c;但是为了适应本文的篇幅&＃xff0c;我作了大量的简化。

注意&＃xff0c;虽然讨论以从 UML 模型到 XML Schema 的转换为主&＃xff0c;逆向转换也很有用。比如&＃xff0c;可能需要在项目中包含其他团队或者公司开发的只提供 XML Schema 的元素。

更强大的样式表

这里重新回顾 上一篇文章中的样式表&＃xff0c;并尝试解决当时提出的两个问题中的一个&＃xff1a;UML 模型中缺少实现信息。造成这个问题的原因有二&＃xff1a;

• UML 是一种通用语言&＃xff0c;因此虽然支持很多建模概念&＃xff0c;但是缺乏针对 XML 的一些概念。比方说&＃xff0c;XML 有元素的顺序序列&＃xff0c;而 UML 没有对概念排序。
• XML 是一种层次化的数据模型&＃xff0c;而 UML 使用更加灵活的图。因此&＃xff0c;UML 和 XML 间有可能存在多种合法的映射&＃xff0c;您必须告诉样式表要采用哪一种。

扩展 UML

从一开始&＃xff0c;UML 的设计者就认识到 UML 可能会被用于没有预料到的用途&＃xff0c;因此实现了扩展机制&＃xff0c;以允许用户改进 UML。

这些扩展机制之一是 构造型&＃xff08;stereotype&＃xff09;&＃xff0c;目的是允许用户在 UML 中定义新的概念&＃xff0c;以精化已有的概念。使用构造型&＃xff0c;用户基本上可以对这种建模工具说“我有一个概念与类&＃xff08;或者对象、参与者、关联&＃xff0c;等等&＃xff09;相似&＃xff0c;但是更加具体。”

从实践的角度看&＃xff0c;构造型是元模型中的一种继承形式。这样有助于把构造型看作是一个 UML 概念的后代。

事实上&＃xff0c;如果读过 UML 规范&＃xff0c;您就会看到标准本身也大量地使用构造型。比如&＃xff1a;

• 注释有需求&＃xff08;requirement&＃xff09;和职责&＃xff08;responsibility&＃xff09;的构造型。
• 约束有不变式&＃xff08;invariant&＃xff09;、前件&＃xff08;precondition&＃xff09;、后件&＃xff08;postcondition&＃xff09;和 stateInvariant 等的构造型。

当然这些都不是用户定义的构造型。

从图形上看&＃xff0c;构造型用包围在尖括号中的关键字表示&＃xff0c;比如图 1 中的 <> 。注意&＃xff0c;UML 允许用户重新定义构造型的图标&＃xff0c;但是很少有工具支持这一特性。

与构造型密切相关的第二种扩展机制是 标记&＃xff08;tag&＃xff09;。构造型允许用户定义新的 UML 概念&＃xff0c;而标记则允许用户存储关于这些新概念的信息。构造型提供了元模型级的继承&＃xff0c;而标记在元模型级提供了向构造型增加类属性信息的机制。

用于 XML 的构造型

我首先说明如何规定一个层次结构。您将定义一个构造型 root&＃xff0c;用于标记 XML 层次中作为根的元素。您将用这个构造型标记一个或多个类&＃xff0c;样式表把它们作为全局元素实现。&＃xff08;在 XML Schema 中只有全局元素才能是根。&＃xff09;

注 意&＃xff0c;可以有多个元素标记为根&＃xff0c;这与 XML Schema 语言是一致的。还请注意&＃xff0c;我决定把这个构造型称为“root”而不是"global“&＃xff08;全局元素&＃xff09;。UML 和 XML 之间可能存在不同的映射&＃xff1a;比如&＃xff0c;您可以在 Schema 中把所有的元素标记为全局性的以便使其能够在其他 Schema 中重用&＃xff0c;也可以把尽量多的元素声明为本地的。&＃xff08;事实上使用全局元素和本地元素背后有一套非常复杂的理论&＃xff0c;请参阅 参考资料。&＃xff09;

我 认为这些实现决策不应该在 UML 模型中公开。一个理由是&＃xff0c;这样做在修改实现规则时不需要重新访问 UML 模型。事实上&＃xff0c;如果把元素标记为“全局的”而又决定改变实现规则&＃xff0c;比方说把所有的元素公开为全局的&＃xff0c;就需要重新查看整个模型并修改多数构造型。我不愿意在 UML 模型中公开过多的实现细节。我准备在下一篇文章中更详细地讨论这个问题。

所处理的词汇表也会影响到把哪些公开为构造型。比如&＃xff0c;如果指定用于出版或者文档应用程序的词汇表&＃xff0c;您可能希望定义一个属性构造型。在处理数据存储的词汇表时&＃xff0c;对映射成属性还是元素&＃xff0c;采用固定的规则可能更合理一些&＃xff08;比如本文中的样式表把一切都映射成 XML 元素&＃xff09;。

用于 XML 的标记

类似的&＃xff0c;我还定义了 position 标记&＃xff0c;用于指定元素在 XML 序列中出现的顺序。这里的问题是模式中的元素顺序在转换成另一个模式时不一定改变。这在处理关联时尤其明显&＃xff1a;UML 工具不对关联排序&＃xff0c;因此不能依靠这些工具按照一定的顺序输出关联。

一种方法是按照名称排序关联&＃xff0c;另一种方法是使用标记明确控制位置。我发现后一种解决方案通常更好一些。

样式表实现

图 2 是一个 UML 模型&＃xff0c;它定义了三个类&＃xff08; person 、 address 和 job &＃xff09;以及彼此之间的关联。该模型是上一篇文章所介绍的模型的扩展。

清单 1是 导出为 XMI 的相同模型。与上一篇文章类似&＃xff0c;这个清单是基于 XMI 标准的&＃xff0c;而不是特定工具生成的 XMI 文档&＃xff0c;但是很容易调整为适应特定的工具。这个列表中新增的内容包括 stereotype、tag、association 和 multiplicity。上一篇文章中已经说明&＃xff0c;解释这些内容需要回顾前面的 UML 元模型。这些内容是按照前面所述的逻辑生成的&＃xff0c;这里就不再添加注释了。

清单 2是样式表的更新版本&＃xff0c;它把这个 XMI 模型转化成 XML Schema。多数新代码都与上一篇文章中介绍的代码类似&＃xff0c;以下几个模板除外&＃xff1a;

• 构造型和标记在 XMI 文件的一开始定义然后被引用&＃xff0c;因此声明两个变量用于保存它们的 ID 非常方便。
• 模型模板选择带有 root 构造型的类声明为全局元素&＃xff0c;其他的类声明为本地元素。如果愿意&＃xff0c;可以改变这一规则&＃xff0c;把所有的元素声明为全局的。
• 类模板遍历关联并使用 position 标记对其排序。
• 关联模板使用特殊的模式遍历关联右端连接的类。这种模式定义了两个模板&＃xff1a;第一个用于带有 root 构造型的类&＃xff0c;插入对类的引用&＃xff1b;第二个用于一般类&＃xff0c;作为本地元素插入类定义。

这里不再给出从 XML Schema 转化成 XMI 的样式表&＃xff0c;留给读者作为练习。

结束语

通过到目前为止所介绍的内容&＃xff0c;您应该已经能够自己编写样式表把任何 UML 模型转化成 XML Schemas 了。我相信&＃xff0c;一旦掌握了这门技术&＃xff0c;您就会发现 UML 建模是设计 XML Schema 最简单的方法之一。

虽然这里介绍的样式表仅限于 UML 元模型的一个子集&＃xff0c;但是为设计更加强大的模型提供了一个很好的起点。

下一篇文章将介绍如何解决最后一个遗留问题&＃xff1a;存在 UML 到 XML 的多种映射时如何设计样式表。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 阅读 Roger Costello 的论文“ Global versus Local”&＃xff0c;文中讨论了不同的设计技术&＃xff0c;使用了富有外国风味的名称&＃xff0c;如威尼斯窗帘和俄罗斯玩偶。
  
  
• 关于完整的 UML 元模型&＃xff0c;请参阅 UML 规范&＃xff0c;可以在 Object Management Group 站点上找到。
  
  
• 研究 IBM Rational Rose&＃xff0c;这是一种领先的 UML 建模产品。 在 developerWorks Rational栏目可以找到大量关于 Rational 和 UML 的资源。
  
  
• 回顾 Benoit Marchal 本系列的前两期文章&＃xff1a;
  • 第 1 部分讨论了 UML 和 XML 模式的关系&＃xff08; developerWorks&＃xff0c;2004 年 3 月&＃xff09;。
  • 第 2 部分介绍了 UML 元模型和 XMI&＃xff0c;后者是一种基于 XML 的模型交换规范。作者然后说明了如何从元模型映射到 XML Schema。&＃xff08; developerWorks&＃xff0c;2004 年 5 月&＃xff09;。
  
  
• 在 developerWorksXML 专区 可以找到数百篇 XML 资源&＃xff0c;包括 Benoit Marchal 使用 XML 专栏的以前各期文章。
  
  
• 在 developerWorks Developer Bookstore可以找到 各种关于 XML 的书籍&＃xff0c;包括 Benoit Marchal 所著的 XML by Example 。
  
  
• 了解如何才能成为一名 IBM 认证的 XML 及相关技术的开发人员。