这两条简单的规则足以将模型中省略的所有信息加上。另外一个好处是,如果我决定改变这些规则(比方说不再使用本地元素),那么需要改变的只有样式表,而不必改变模型。如果这些细节写入模型,那么模型也需要更新。
但不能过于简化您可能不同意我对属性所持的观点。虽然属性在这个特定的应用程序中不重要,但是您的应用程序可能不同。不同的项目强调 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)。使用适当的建模工具,再加上我提供的样式表,就可以开始了。