GB/T 28174.4-2011 统一建模语言(UML) 第4部分：图交换

　　ICS 35. 080 L 77

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 28174.4—2011

　　统一建模语言(UML)

　　第 4 部分 : 图交换

　　Unified modelinglanguage(UML) —Part4:Diagram interchange

　　2011-12-30发布 2012-06-01实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　

　　发

　　

　　布

　　GB/T 28174.4—2011

　　目 次

　　前言 Ⅲ

　　引言 Ⅳ

　　1 范围 1

　　2 规范性引用文件 1

　　3 附加信息 1

　　4 体系结构概览 3

　　5 元模型扩展 5

　　6 表示视图的推导 16

　　7 表示 SVG包元信息到 SVG 图 19

　　附录 A (资料性附录) 指派图元素 21

　　附录 B (资料性附录) 一个 XMI[DI]例子的摘录 23

　　Ⅰ

　　GB/T 28174.4—2011

　　前 言

　　GB/T 28174《统一建模语言(UML)》分为 4个部分 :

　　— 第 1部分 :基础结构 ;

　　— 第 2部分 :上层结构 ;

　　— 第 3部分 :对象约束语言(OCL) ;

　　— 第 4部分 : 图交换 。

　　本部分为 GB/T 28174的第 4部分 。

　　本部分按照 GB/T 1. 1—2009给出的规则起草 。

　　本部分参考面向对象工作组(OMG)的《统一建模语言 : 图交换》2. 0 版 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别这些专利的责任 。

　　本部分由全国信息技术标准化技术委员会(SAC/TC28)提出并归 口 。

　　本部分起草单位 :广东万维博通信息技术有限公司 、北京大学 、广东省广业信息产业集团有限公司 、中国电子技术标准化研究所 。

　　本部分主 要 起 草 人 : 江 善 东 、黄 孝 和 、杨 三 宝 、吴 炯 祥 、邓 海 强 、胡 红 林 、许 立 勇 、周 伟 强 、唐 泽 欢 、高健 。

　　Ⅲ

　　GB/T 28174.4—2011

　　引 言

　　统一建模语言(UML)是一种可视化规约语言 ,用于定义和构造计算机信息系统的制品,并将其文档化 。它是一种通用建模语言 ,可以和所有主流的面向对象和面向构件的方法一起使用 ,并适用于所有的应用领域和实现平台(如 :CORBA、J2EE、. NET等) 。

　　0. 1 统一建模语言不同版本之间的关系

　　由于 UML 的技术较新 ,所以该国际标准历经多次的版本演化 ,下面是 UML在 OMG 的演化过程 : 1997 UML1. 1

　　1998 UML1. 2

　　1999 UML1. 3

　　2001 UML1. 4

　　2003 UML2. 0

　　GB/T 28174的本部分正文中的 UML均指 UML2. 0 统一建模语言和 GB/T 28174。

　　0. 2 关于对读者的建议

　　需要了解语言中的元模型构造物 ,利用这些构造物进行元模型扩展或者是构造新的建模语言的用户可阅读基础结构部分(GB/T 28174. 1) 。

　　应用系统建模用户和建模工具制造方都需阅读上层结构部分(GB/T 28174. 2) 。但要注意 ,该部分的内容是交叉引用的 ,可不按目次顺序阅读 。

　　对于要精确地对模型进行约束的应用系统建模用户或要支持对象约束语言的建模工具制造方 ,需阅读对象约束语言部分(GB/T 28174. 3) 。

　　支持在不同的软件工具间平滑且无缝地交换文档的建模工具制造方 ,需阅读图交互部分 。

　　0. 3 关于本部分

　　本部分的目标是使在不同的软件工具之间对兼容 UML标准的文档(以下称作 UML模型)进行平滑无缝的交换成为可能 。它不仅包括用于开发 UML模型的工具 ,也包括白板 、代码生成器 、字处理工具 、桌面发布工具 等 。 同 样 的 , 对 于 作 为 交 换 和 展 现 UML模 型 的 媒 介 — 互 联 网 , 也 要 给 予 格 外 的关注 。

　　已有的一种交换 UML模型的机制 ,称为 XML元数据交换(XML Metadata Interchange)(以下称作 XMI[UML]) ,并没有完全达到模型交换的目标 。最重要的是它没有包含图信息的交换 。该机制仅仅能够传递在一个 UML模型中包含哪些元素的信息 ,但是没有这些元素在图中如何表现和布局的信息 。 因此 ,如果 UML模型存储在一个 UML工具中而又被另一个不同的 UML工具(或者甚至是同 一个工具)用 XMI[UML]载入 ,那么所有的图信息就会丢失 。这个局限性并不是 XMI本身的错 , 而是由于这样一个现实 :UML元模型没有定义一个标准方法来表现图的定义 。

　　本部分是用一个附加的面向图形信息的包来扩展 UML元模型 , 同时完全保留当前 UML元模型的完整性 。此外 ,它还兼容 UML元 模 型 , 并 且 不 被 UML元 模 型 后 来 的 任 何 变 化 所 影 响 。 为 了 表 示

　　Ⅳ

　　GB/T 28174.4—2011

　　UML 图信息 ,一种兼容 MOF的元模型被提出来 ,作为 UML元模型的扩展 ,还允许扩展 XMI的 DTD。那么 XMI就能够用来在各种各样的工具之间交换 UML模型而不丢失信息 。

　　为了保证需要交换的工具没有模型元素的概念而只有线 、文本和图形 ,一种从 XMI到 SVG 的转换机制被提出来 。 SVG 是一种用来表示标量向量图形的基于 XML 的格式 , 作为 W3C 的推荐被 采 用 。由于对表示任何 UML 的图它都有良好的适应性 ,它将成为一种在各种各样工具(图形的 ,桌面发布的 ,等等)中普遍采用的格式 ,并且被创建得适合网络应用 。

　　结合其他的基础结构部分(GB/T 28174. 1) 和上层结构部分(GB/T 28174. 2) 的严格定义 ,本部分将使一种 UML模型之间平滑无缝交换的机制成为可能 。

　　Ⅴ

　　GB/T 28174.4—2011

　　统一建模语言(UML)

　　第 4 部分 : 图交换

　　1 范围

　　GB/T 28174的本部分规定了用于对各类软件系统进行可视化 、详述 、构造和文档化的统一建模语言 。该语言也可用于对其他领域进行建模 。

　　本部分适用于在不同的软件工具间平滑且无缝地交换文档 。 这些工具可以是 UML建模工具 、代码生成器 、词处理工具和桌面出版工具等 。本部分也可用作在因特网上交换和表示 UML模型起媒介作用的规范 。

　　图交换没有可选的兼容点 。 和图交换相兼容意味着和它的抽象语法 、良构规则 、语义 、符号 , 还有XMI相兼容 。指派图元素见附录 A。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的 。凡是注 日期的引用文件 ,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件 ,其最新版本(包括所有的修改单)适用于本文件 。

　　GB/T 28174. 1 统一建模语言(UML) 第 1部分 :基础结构

　　GB/T 28174. 2 统一建模语言(UML) 第 2部分 :上层结构

　　3 附加信息

　　3. 1 概念考证声明

　　本部分中提及的元模型已经用一套不同的图实现和测试了 。提出的概念都是被证明过的 。

　　在整篇文档中使用并且在附录 B 中提供的例子 , 目前对它相应的 XMI表示的转换更多是用手工而不是自动完成的 。然而 ,针对所提供的 DTD,这个例子是有效的 ,并且使得用 XSLT 转换到 SVG 成为可能 。

　　3. 2 设计的基本原理

　　UML是一种强调图形 化 表 示 的 面 向 对 象 软 件 系 统 的 建 模 语 言 。 它 在 整 个 软 件 开 发 过 程 中 被 部署 ,并且在这个过程中有大量多种多样的工具可以使用 。工具之间差别很大 :存在变化很大的方法来设计图 、检查模型的一致性 、存储模型用于永久存储或者版本管理 ,用于代码生成 ,用于准备文档 、呈现或者制定文档以及很多更多的应用 。

　　对这些多样的工具毫无问题地进行无缝使用和联合是非常有价值和令人期望的 。 因此 ,一种模型信息的表示(从而包括交换)机制被包含在最初的标准中 。尽管如此 ,UML1. x 中安排的机制仅仅支持在模型中元素的定义 。虽然这对于检查模型一致性或者生成代码的工具来说是必要的 ,但这些信息面向图形的工具来说并不够 。 因而就把广大利用图形信息的工具排除在外 ,其中也包括 UML工具本身 。

　　考虑到这方面 ,UML1. x 的模型交换机制就显得不足 ,而 OMG则发现并满足了改正这一缺陷的需要 。 OMG 内部用来传送元信息的一般实现机制是 XMI。 XMI是一个用它 自 己来传送内部非常有参

　　1

　　GB/T 28174.4—2011

　　考价值信息的 XML应用 。 面向对象的模型和这样模 型 的 模 型 都 属 于 这 个 类 型 , 但 都 只 是 一 个 例 子 。 XMI通过在具体的 UML元模型中应用 XMI的规则生成一个特殊的 DTD,用来传送 UML模型 。 为了区别通常意义的 XMI和它针对 UML 的应用 ,在本部分中我们将把后者记作 XMI[UML] 。尽管图形信息没有包含进来 ,这一机制也已经被证明是非常有用的 。

　　UML图 ,正如 UML模型 ,可以用元模型来描述 。本部分为图信息提出了一个单独的元模型 ,它能简单地作为一个独立的包加入到现有的 UML元模型中 。并且就像带有元模型的 UML,XMI能够用来传送这种图的元模型的实例 。相应的 DTD(简单地扩展了 XMI[UML]的 DTD)直接从元模型生成 ,并且在本部分中也提供了 。 这种格式这里将记作 XMI[DI] 。 两者 的 联 合 , 组 成 了 完 整 的 模 型 交 换 机制 ,将表示为 XMI[UML+DI] ,或者简记为 XMI。

　　在当前的标准中 ,一个 DTD被生成来描述 XMI[UML]和 XMI[DI]的部分 。在未来标准中 ,可以使用 XLink 来 引 用 其 他 的 模 型 元 素 , 两 个 部 分 可 以 放 在 不 同 的 文 件 中 , 允 许 为 每 个 部 分 生 成 不 同的 DTD。

　　本部分中提及的元模型与 MOF元模 型 工 具 一 致 。 XMI定 义 了 如 何 从 适 合 MOF 的 元 模 型 创 建DTD或者模式 , 以及如何把它应用于 XMI。 因此 ,一旦对一个适合 MOF的元模型达成协议 ,就会考虑到它在 XMI中的表示和相应的 DTD。

　　元模型本身由两个目标发展而来 。首先 , 它应该灵活地扩展现存 UML元 模 型(也 包 括 将 来 的 版本)而不需要妨碍和修改它 。 同时它还应该携带尽可能多的多余信息 ,通过引用 UML元模型来访问这些信息 。第二 ,它应该允许任何工具从得到的信息简单地描绘图 。这当然包括 UML工具 ,也包括网络浏览器 、办公套件 、图形编辑器等 。

　　各种工具需求有很大的不同 。UML工具通常要能够用线条和文字本身来表现模型元素 , 而文本编辑工具就完全没有模型元素的概念 ,只是需要一幅图以普通的图形形式出现 。但图形工具就典型地需要一种丰富的面向向量格式 ,用来做复杂的操作和缩放 。

　　SVG,标量向量图形格式 , 是一种新的 W3C标准 , 它承诺能够被广大的各种各样的工 具 所 支 持 。它以 XML为基础 ,能很容易地读入 、处理 , 以及转换成其他的多种格式 。 它同样适合文本工具 、办公套件和图形工具 。此外它还适合即将直接支持它的网络浏览器(但是在这段过渡时期可以使用一个免费的 Adobe插件) 。

　　然而 ,SVG并不是一个很适合 UML工具的机制 。UML工具并不只是需要线条和文本 ,它还需要高层次的信息 , 因为它们不仅仅以图形方式显示图 ,它们还要求对用图形元语表示的模型元素有语义上的理解 。

　　但是 XML 的巨大优势之一就在于 ,只要所有需要的信息都被呈现出来 , 以一种 XML数据格式表示的数据能够很容易地转换成另一种不同的 XML数据格式 。 因此本部分提出了一个用 XMI[DI]传送的元模型和提供了一种用 XSLT从 XMI[UML+DI]到 SVG 的转换方法 。 这个方法满足了最广阔范围内工具的需要 。所有其他要用的格式都可以通过这个方法来产生 。

　　因此 ,通常用来表示附加信息以允许 UML 中所有图进行交换的抽象(abstraction) 是什么呢? 一个可选的方案是为组成 UML 图的每一种形状引入特殊的类 ,如果 UML需要扩展 ,或者它的范围扩大了 ,或者如果核心机 制 将 被 别 的 建 模 符 号 复 用 , 这 种 方 法 就 显 得 太 不 灵 活 了 。 图 的 交 换 不 应 该 限 制UML 的可扩展性 。如果可能的话 , 图交换机制不应该有具体的形状或者其他元素的表示法 。具体图形状的画法是 UML工具或者 SVG描绘器的职责 。

　　可以发现 UML 中的大多数图符合从图形理论得出的图形模式 :它们由结点(可能是矩形 、椭圆 、圆或者其他形状)和边(连接结点之间的线 、末端不同的箭头和形状)组成 。结点可以包含分隔和图注 ;边也能有附加的图注 。有些结点能嵌套到其他结点中 ,带有连接两个结点的边(有的情况下这两个结点也可以和边连接) 。

　　这种图形模式是功能强大的和能被很好理解的一种抽象 ,在可视化建模的很多领域都有应用 。在

　　2

　　GB/T 28174.4—2011

　　该标准中使用这种抽象是因为正像将要讨论的那样 , 它被证明是完全足够的 。 大多数 UML 图都有 一个到图形的自然而直截了当的映射 。类图 、用况图 、协作图 、对象图 、构件图以及部署图都是这种情况 。在当前 UML 的形式下 ,只是顺序图没有这样到结点和边的 自然映射 ,但还是能明显地发现一种映射 。要讨论的是 :尽管基于图形的方法可能不是所有图类型显而易见的选择 ,但它适合于大多数 ,并且完全足够表示任何现有的和将来的 UML 图类型 。

　　4 体系结构概览

　　4. 1 概述

　　从 XML[UML]到 XMI[UML+DI]的扩展使用了一些技术来创建它的元模型以及被提及模型的示例对象 。相关的技术已经被发布为 OMG 和 W3C 以及任何能够自由利用它们的人使用的标准 。 而在这一过程中作为其 他 相 关 技 术 基 础 的 基 本 技 术 , 则 是 XML。 它 由 一 些 基 本 的 规 范 组 成(如 良 构 规则) ,用来指导如何创建文档 ,及如何用标记来描述它们的内容 。这种广泛接受的机制能被世界上许多工具所支持 。

　　4. 2 XMI[DI] DTD创建概览

　　图 1 提供了一个在元模型和 DTD创建过程中相关技术的概览 。

　　图 1 XMI[DI] DTD创建概览

　　XMI[DI]元模型由 UML建模工具创建 。 利用这个工具 , 可以用 UML 为 MOF外廓创建一个符合 MOF的元模型 ,用来描述 UML 的 M2扩展 。 为了和 XMI的规范相一致 ,该工具需要有能力创建XMI[UML]文档 。这是一种满足 XML所定义的规范文档 ,并且包含 XMI[UML] DTD。这一步骤由XMI文档产生规则来体现 。正如刚才所提到的 ,它产生符合 XMI的文档 ,并且包含在 UML工具的帮助下创建的元模型的内容 。为了给 XMI[UML+DI]生成新的 DTD,新的 M2应通过将 XMI[UML]文

　　3

　　GB/T 28174.4—2011

　　档翻译成 XMI[MOF]文档来表示成 MOF的形式 。从外廓到 MOF 的映射规则包含在 MOF 的 UML外廓中 。另一个方案则是通过使用 CASE工具直接生成 XMI[MOF]文档 。最后 ,XMIDTD 的产生规则能够应用到 M2的 MOF描述中 。运用这种为 XML模式规范而出现的 XMI产生规则 ,一个 XML模式也能够被生成出来 。

　　以该扩展 XMI[UML+DI]元模型为基础 ,现在就有可能在交换 XMI[UML]模型的时候把图信息包含进来 。此外还能创建一些关于模型的描述 。一个方案是用 SVG来创建这种描述 。

　　SVG(标量向量图形 ,Scalable Vector Graphics)是一种用于描述向量化图形的技术 ,它以清晰文本(基于 XML 的)格式描述向量化图形 ,并且在此之上产生出可视化效果 。它由 W3C发布为一种推荐格式 。与普通图形比较 — 比如位图格式—SVG使得对图形的缩放 、旋转以及在该技术中对单个元素的方法调用成为可能 。它同样也能处理和用户之间的交互 ,这就为在基于 SVG 的图形之上工作提供了多个选择 。

　　W3C 的另一推荐 XSLT(可扩展的样式表语言 , eXtensible Stylesheet Language) 定义了如何创建为从一种 XML文档到另一种(通常也是 XML)文档的转换创建样式表(它们本身也是 XML文档) 。在这种情况下 ,样式表用来把包含 UML模型和图信息的 XMI[UML+DI]XML文档转换为能够被浏览器显示的 、包含完整图形翻译信息的 SVG XML文档 。 注意 ,用来实现样式表驱动转换的 XSLT 引擎通常在开放源代码中间是可用的(Apache项 目 中的 Xalan就是很显著的例子) 。

　　4. 3 SVG 图形创建概览

　　图 2 提供了一个从 UML建模工具创建 SVG文档过程中相关技术的概览 。

　　图 2 SVG 图形创建概览

　　4

　　GB/T 28174.4—2011

　　由于在创建 XMI[DI] 扩 展 的 时 候 , 起 点 是 用 一 种 UML建 模 工 具 来 描 述 一 个 模 型 。 基 于 这 个 模型 ,用 XMI产生规范就能创建 XMI文档 。结果又是该 XMI文档包含了所需内容 ,并且还包含了模型的图形信息 — 这一点和以往的方法不同 。相对于 XMI[UML] DTD 为了检查 XMI文档的语法正确性而包含 XMI[DI]扩展 ,这种方法是很有效的 。 除此之外 , 良构规则也同样总是要检查 。 下一步是从XMI的源文档创建 SVG文档 。这个工作由 XSLT样式表完成 , 它只要产生一次就能够用于所有同时包含模型和图信息的 XMI文档 。对 XMI[UML+DI]源文档应用这种样式表就能生成 SVG 文档 , 而SVG文档又能够由 SVG查看器还原显示为图 。使得通过翻译输入文档就能将模型可视化 。 多种不同的查看器 ,其中包括一些因特网浏览器中的集成插件的存在使在浏览器中通过较高层的用户交互来观察和操作 UML 图成为可能 ,并且这种交互可以设计得如同 目前的 UML工具一样直观和简便 。

　　5 元模型扩展

　　5. 1 概述

　　本章描述了图交换机制所依赖的元模型 。它是 UML元模型的一个扩展 。现有的用于模型交换的XMI[UML]机制只包含了模型信息而并没有包含图信息 。 图交换扩展则允许在 UML模型中用到的图以图形化的信息包含进来 。

　　该扩展在现有 UML元模型包中加入了一个新的包 ,但并没有改变现存的标准 。 同样 , 只要高层的概念 —Core: :Element(用于 UML1. x) ,Elements: :Element(用于 UML2. 0 和所有基于通用核心的元模型)继续保持 ,针对版本更新所做的 UML元模型更改也不会影响该模型 。该扩展和 UML元模型很大程度上保持独立 ,使得从扩展模型到 UML元模型的单独链接被包含进来 。这样 , 图形化的和模型的信息被清楚地分开了 。

　　此外 , (该扩展)还避免了各种工具在对现有标准支持上的冲突 ,保持了完全的向后兼容性 ,并提供了对未来 UML 自身扩展的适应性 。

　　本部分包中包含了这样一些元素 ,它们能反映 UML标准中任何一种图元素的图信息 。具体工具的扩展可以定义在附加的包里 。 比如说 ,如果工具增加了绘制额外形状的能力 ,那么可以提供一个附加的包来描述这些能力 。这样做的目的是 , 即使是不支持这些附加扩展的工具 ,也能够保证通过简单地忽略掉那些来自附加包的信息来生成图形化的表述 。 图 3 描述了被提议的用来表述图信息的元模型 。

　　5

　　GB/T 28174.4—2011

　　图 3 图交换元模型

　　6

　　GB/T 28174.4—2011

　　5. 2 扩展图形模型

　　该元模型扩 展 的 底 层 概 念 基 于 将 UML 图 看 作 图 形 来 对 其 内 容 进 行 建 模 的 思 想 。 核 心 类 是GraphNode和 GraphEdge。每一个可见的模型元素都由 GraphNode或者 GraphEdge来表现 。 图形元素的基本类是 GraphElement。 图形元素通过一个叫 GraphConnector的类相互链接起来 。这使得一个GraphEdge类能够链接到一个 GraphNode类或者另一个 GraphEdge类 。后一种情况是纯数学图形概念上的扩展 。GraphConnector类不允许两个 GraphNode类互相链接 。

　　一个 GraphElement类能拥有任意多个 GraphConnector,这些 GraphConnector被称作锚点 。它们允许任意数目的 GraphEdge来链接 。 一个 GraphEdge引用两个 GraphConnector, 它们是它的链接端点 。从 GraphEdge的角度来看 ,这些称作锚 。这两个 GraphConnector作为相应 GraphEdge的路点以相同的方式排列 ,第一个 GraphConnector对应第一个 GraphEdge的路点 ,第二个 GraphConnector对应最后一个路点 。

　　这 里 并 不 强 迫 GraphConnector 和 引 用 它 的 GraphEdge 的 端 点 有 相 同 的 位 置 。 当 被 多 个GraphEdge引用时 ,它就作为各个 GraphEdge的虚拟连接点 ,例如 ,如在一个结点中间或是在另一个表示结点的特殊点 。所有带链接的 GraphEdge都直接指向 GraphConnector,然而它的路点则有可能 , 比方说 ,被定义为带链接的结点图形边界的结束位置(图 4) 。读入这个信息的 UML工具可能会把它解释为裁减(clipping) ,这或许对更进一步的编辑有一些帮助 。

　　图 4 放射状边缘的 GraphConnector示例

　　5. 3 嵌套

　　这种关联容器— 包含物介于图形元素和图元素之间 — 组成了纯数学图形更进一步的扩展 。它允许构造层次化嵌套元素 。每一个图形元素都能包含无限多个图元素 , 因此它可能包含整个子图 。这种嵌套层次在对复杂模型元素的表述进行建模时尤其有用 。

　　打个比方 ,类由 GraphNode来表示 ,它又拥有嵌套的 GraphNode,其中含有图元素 ,用来表示框 , 比如 ,操作 框 、属 性 框 等 。 这 样 用 来 表 示 框 的 GraphNode, 如 一 个 属性 框 , 拥 有 更 深 层 次 嵌 套 的

　　7

　　GB/T 28174.4—2011

　　GraphNode,其中包含用来表示属性的图元素 。而属性的 GraphNode又嵌套包含表示部分属性的图元素 ,如可见性 、名称 、类型或初值等 。

　　图 5展示了把一个简单类表示成嵌套图形元素的例子 ,这里的图形元素是 GraphNode。 为了表示更复杂的类 ,需要包含更多嵌套的 GraphNode。

　　图 5 类表示中嵌套 GraphElement的例子

　　5. 4 叶结点

　　图形元素的图形化表述很大程度上起源于语义模型(见后面) , 同时为了避免冗余并不显式地存储在 DI模型中 。 比如说 ,把类画成一个矩形的知识并没有存储在 DI模型中 。但注意 ,如果有必要的话 ,它的位置和大小要存储起来 。绘图工具和 XSL样式表应具有正确绘制这些元素的语义知识 。

　　叶元素 可 以 表 示 有 特 殊 可 选 表 示 方 法 的 模 型 元 素 , 比 如 参 与 者 。 如 果 一 个 表 示 参 与 者 的GraphNode拥有用户定义(见后面)的语义模型桥的表述 ,那么它应要有一个叶结点作为子结点 。这个叶结点表示了该参与者的可视化 。

　　叶元素可以是显示一段简单文本的文本元素 ,显示一个简单图形的图形原语(GraphicPrimitive) ,如椭圆 ,也可以是一幅用来显示外部资源的图像 。

　　两个基本的专门图形原语是本部分的一部分 :折线(Polyline)和椭圆 。其他图形原语可以在额外的包中定义并且可以从 GraphicPrimitive类或其子类中继承 。文本元素用来表示部分的属性 、操作 、名称和模型元素的其他文本部分 。 比如说 ,一个属性的可见性就可以是一段文本 ,如“public”或“+ ”。这段文本就存储在文本元素的 text属性中 。TextElement的容器 GraphNode拥有一个到语义模型的链接 ,该语义模型以简单语义模型元素(SimpleSemanticModelElement) 的形 式 出 现 。 该 链 接 指 出 了 被 引 用属性的部分 。在这个例子中 ,简单语义模型元素的类型信息属性包含了可见性 。属性的命名规则将在5. 13中描述 。 图 6举例说明了所涉及类的相关部分 。表示 GraphNode名称的简单语义模型元素没在图中显示 。

　　8

　　GB/T 28174.4—2011

　　图 6 TextElement示例

　　如果可见性用一个图标来表示 ,TextElement将被另一个 LeafElement所取代 。 如果该图标是作为图像存储在另一个文件中 ,则 LeafElement是一幅图像 ,该图像引用了那个文件 。

　　用到很多次的 LeafElement只需要实例化一次 。这些 LeafElement直接被 Diagram所包含 。每次用到这样的 LeafElement时 ,一个该 LeafElement的 引 用 就 被 实 例 化 , 而 不 必 拷 贝 一 份 LeafElement。 isIndividualRepresentation标记被设为 true,用来区别于在后面描述的 Reference 的应用 。这就避免产生同一个可见成分的多个拷贝 。

　　5. 5 图

　　5. 5. 1 概述

　　一个特殊的结点是图(Diagram) 。 它是任何一个图形或图的顶层图形元素(GraphElement) ,递归地包含所有其他的图形元素 。一个图拥有一个名称和一个视 口 (Viewport) 。该视口是一个点 ,指出了这个图左上角的可见部分 。它也有一个缩放的因子 ,允许视口以不同的比例显示 。 图的类型存储在 一个简单语义模型元素中 , 如状态图 。 图通过它的语义模型(SemanticModel) 来引用它 。 一个图形元素能够通过一个图链接(DiagramLink)链接到图 。如果一个图形元素可以被其他图所表示 , 比如 ,在一个更详细的层次上 ;或者如果该图形元素跟其他的图有特殊的语义关系 ,那么就可以使用这样的链接 。 图链接拥有它自己的缩放因子和视 口 ,所以每一个图能在各自的上下文环境中以不同的缩放因子和视 口显示 。使用图链接的一个例子是状态图 ,它用来显示类的行为 ;或是类图 ,用来显示包的细节 。

　　图 7通过对象图给出了图的一个简单例子 。它显示了通过关联链接到一起的两个类的类图 。 图和类通过 GraphNode来表示 ,而关联则用 GraphEdge来表示 。该对象图也显示了 GraphConnector在链接 GraphNode和 GraphEdge中所扮演的角色 。

　　9

　　GB/T 28174.4—2011

　　图 7 一个类图示例(仅描述了 UML[DI]的部分)

　　5. 5. 2 图的命名空间

　　通常 UML 的元素会被指派到一个 UML 的命名空间 ,然而图元素则不用 。 只要图元素的语义模型桥接(SemanticModelBridge)(见后面)引用了一个拥有命名空间的 UML元素 ,那么它就不需要命名空间 。如果不是这种情况 ,它周围作为容器的图元素会拥有一个命名空间 。尽管如此 ,这个规则还是有一个例外 : 图没有命名空间并且也没有包含它的图元素 , 因为它自己就是顶层容器 。

　　因此 , 图也需要一个命名空间 。 图的命名空间通过语义模型桥接被语义模型的一个命名空间元素的引用所指派 。从图那里通过这种方式引用的元素应是 Namespace的一个子类 。

　　5. 5. 3 在一个图中显示另一图的剪切图案

　　一个图可能被用来显示从另一图中摘取的部分 ,而不必多次创建要用到的图元素 。 比如说 ,为了得到更好的表示效果 ,一个大的图可以通过几个小一些的图来表示 。为了达到这样的目标 ,大的图要拥有所有它的包含在内的图元素 , 同时那些剪切出来的图只要包含对原来的图元素的引用 。在一个被引用指向的 、剪切出来的图中 ,只有这些图元素才被显示 。 引用和单独的图元素可以在同一个图中独立被使用 。

　　5. 5. 4 图元素的可见性

　　可见性(visible)这个属性指明了一个图元素是不是正在被显示 。在所有包含的图元素中 , 它的值被递归地应用 。 只要在该递归层次中有一个图元素把它的这个属性设为 false,那么不管它们原有的可见性如何 ,所有嵌套的元素也都隐藏了 。

　　当一个隐藏元素不被显示时 ,它仍然存在 。这就意味着如果它由于该属性值被设为 true而显示 ,那么该元素将和从前一样以相同的方式出现 。这就提供了一个轻松的方法来使一个框(compartment)淡出 , 比如当保持它的表示时 。这使得一个先前隐藏的图元素稍后再次显示变得容易了 。

　　5. 6 性质

　　图元素的出现是用性质加以指定的 。性质可以添加到 DiagramElements,在不同方面影响它的出现 。表 1定义了一个可选择性质的标准集 :它包含了字体 、大小 、线的格式 、粗度和颜色 。每个性质都覆盖了任何一个和它相同的封装了的 GraphElement的已经存在的性质 。 如果一个性质没有被设置 ,那么 DiagramElements就利用它的容器 GraphElement所包含的性质 。非标准的性质可以被添加但不属于任何标准化 。性质为添加非标准的元素到图交换元模型提供了一个扩展机制 。

　　10

　　GB/T 28174.4—2011

　　表 1 标准性质

　　关键字

　　域

　　举例

　　描述

　　FontFamily

　　string

　　‘Times’,‘Courier’

　　fontname

　　FontSize

　　double

　　11

　　fontsize in pixel

　　LineStyle

　　string

　　‘solid’,‘dotted’

　　line style

　　LineThickness

　　double

　　2

　　line thickness in pixel

　　FontColor,

　　ForegroundColor, BackgroundColor

　　integer

　　FF00FF for magenta

　　24-bitcolorvalue in RGB format

　　Translucent

　　boolean

　　true,false

　　see text

　　GraphElement 的 性 质 Translucent被 设 置 为 True是 为 了 指 出 它 们 包 含 的 元 素 通 过 包 含 的DiagramElements的背景可见(见顺序图) 。

　　5. 7 坐标系

　　在图交换扩展关系应用的坐标系统定义 x 轴指向东、y轴指向南 。位置和大小通过两个值来定义 ,它们利用像素来作为度量单位 。浮点型 double允许低像素的精确度 。 这防止了当度量转换或其他图操作时产生可能的信息丢失 。

　　5. 8 位置

　　一般来说 ,这个模型的所有的位置值都是相关的 ,也就是图元素的所有位置值都和它周围的容器相关 。这意味着这个容器的位置是所有子的位置的原点 。 为了得到一个图元素的绝对位置 ,应递归地从容器 GraphElement到没有容器的 GraphElement, 根就遇到了 。 根结点应是一个图 , 因为只有图没有容器 。

　　GraphElement的位置是由 StructureType点来指定的 。 它指定了一个 GraphNode或 Diagram 的左上角的位置 。一个位置的 x、y坐标可以为负值 。

　　对于 GraphEdge,位置为所有包含的 DiagramElements提供了一个原点 。 因为一个 GraphEdge是通过它的路点(waypoint)来定义的 ,所以位置不影响 GraphEdge本身的图形表示 。通过它的所有路点(贝塞尔点的一种类型)把它画成贝塞尔曲线 。控制点被定义成相关于基本点 。 因此 ,如果所有的控制点都是(0,0) ,结果就是一个简单的多边形线 。

　　一个图不需要有一个环境容器元素 。它的位置缺省值为(0,0) 。视口指定了图中当前显示视图的左上角坐标 。视口如果被卷动则它不再是(0,0) 。

　　相对坐标允许层次嵌套结点可以通过改变根结点的位置来被轻松地移动 。例如 ,想移动一个类 ,可以用改变表示这个类的 GraphNode 的位置来实现 。所有包含的图元素自动和这个类一起移动 , 因为它们的位置和它相关 。

　　5. 9 大小

　　对于 GraphNode,可选择的大小可以用 DataTypeDimension来提供 ,它包括了类型为 double 的宽和高 。这些都不允 许 为 负 值 。 如 果 大 小 没 有 被 提 供 , 则 它 由 它 的 语 义 模 型 和 GraphNode 中 的 嵌 套DiagramElements来决定 。考虑下面两种情况 :

　　11

　　GB/T 28174.4—2011

　　a) 如 果 语 义 模 型 显 示 对 GraphNode 的 图 形 表 示 是 需 要 的 , 它 的 大 小 应 由 嵌 套 的DiagramElements计算出来 。例如 ,如果未给出 ,表示一个类的 GraphNode 的大小应被递归地检查外面包含的层数来决定 。如果一个框的大小没有给出 ,那么它包含的 DiagramElements,例如属性 ,应被分析等 。

　　b) 如果语义模 型 指 定 一 个 没 有 图 形 表 示 或 有 一 个 固 定 的 图 形 表 示 的 语 义 模 型 的 Elements,计算也是不需要 的 。 这 种 情 况 的 例 子 是 关 联 端(AssociationEnd) 。 举 例 来 说 , 尽 管 包 含 多样性 TextElements和任 务 名 的 GraphNodes 也 许 会 嵌 套 在 这 样 一 个 GraphNode 中 , 但AssociationEnd 的 GraphNode本身没有大小— 它只被用作容器 。就算 AssociationEnd是可见的 ,例如一个 实 心 的 菱 形 来 表 示 组 合 , 它 也 被 考 虑 为 一 个 固 定 的 图 形 表 示 , 所 以 没 有长度 。

　　5. 10 描绘顺序

　　一般的图元素顺序描绘是通过如下两个机制来定义的 :

　　a) GraphElement中 DiagramElements的嵌套树优先级最高 。为了描绘 DiagramElements,用 一个前序遍历来处理树 。这意味着一个路径最深层嵌套的 DiagramElements被最后画 ,所以被显示在 z-order的顶端 。

　　b) 顺 序 关 联 容 器 — 包 含 在 GraphElements 和 DiagramElements 之 间 — 指 定 了 这 个 相 同GraphElement中包含的 DiagramElements的表示顺序 。第一个 DiagramElement先画 ,第二个其次 ,等等 。

　　还有一种不常见的情况中只用这种直接表示的概念就不够了 。利用 LeafElements去充实一个图 ,这些元素不属于 UML。为多个 GraphElement显示这样一个作为背景的 LeafElements可能会有用 。这种情况的一个例子是一张图像上画的椭圆 。这个椭圆包含两个不同包 a、b 中的类 a、b,所以被画在这两个包的上方 。

　　图 8显示了这种情况 。

　　图 8 一个包含 DiagramElements的树的两条路径的椭圆

　　不可能用以上描述的两种机制来表示图 8, 因为任何 DiagramElements, 比如这个图像 ,也许仅仅是 DiagramElements的树的一个单 一 路 径 的 部 件 。 为 了 用 这 种 方 法 显 示 出 来 , 它 应 是 两 个 路 径 的 部件 。为了达到这个目的 , 利用了 Reference。这个图像被包含在 DiagramElement的 一 个 单 一 路 径 中 。如果它想显示其他任何路径 ,包含了 Reference。它的指向图像的参考指示它是两个路径的部件从而被表示 。

　　12

　　GB/T 28174.4—2011

　　5. 11 语义模型

　　图交换元模型允许图用一个增加的语义内涵来表示 ,方法是通过抽象的语义模型桥接来链接一个存在的语义模型的元素 。每个 GraphElement有一个到 SemanticModelBridge的具体子类的链接 。 如果不是一个 SimpleSemanticModelElement,则它参考链接的语义模型的最高层父类 。

　　注 : 在 UML1. x 中这是包 Core的 一 个 类 Element, 它 用 UML1SemanticModelBridge为 参 考 。对 于 UML2. 0 和 其后版本 ,这可以是包 Kernel的类 Element,用 CoreSemanticModelBridge作参考 。这个链接允许添加 UML-指定信息到图形 。其他的语义模型也可以添加 ,例如 ,ER 图 。

　　设计这个模型是为了减少冗余的信息 。 出于这个动机 ,没有作更多的努力去显示元素的语义类型 。为了知道一个元素的语义模型 ,应检查 SemanticModelBridge。如果这个具体子类有到语义 模 型 的 元素的链接 ,所有可用的关于这个元素的语义信息都可以得到 。

　　5. 12 元素的预定义表示

　　有些元素允许有多于一个的标准表示 。 例如 , 一个参与者可以显示为一个矩形或一个棒棒人形 。为了区分这些情况 ,属性“presentation”定义在 SemanticModelBridge指的是所要求的表示 。这避免了去创建复合 DiagramElements,比如图像去显示标准元素 。

　　为了使一个元素标准可见 ,表示应被设置成 “”, 即空串 。对于非标准的处理 ,它应被置成 “UserDe- fined”。这意味着它通过关联在元素的 GraphElements 中的 DiagramElements来指定 ,严格地显示出来 。 因为绝大多数元素只有一个严格的标准表示 ,表 2 只列举了那些明确包含一个以上的 。其他的我们收集在条款[SinglePresentation]下面 。

　　表 2 SemanticModelBridge表示的允许的值

　　元素

　　SemanticModelBridge. presentation

　　[Single Presentation]

　　‘’(Default) ,‘UserDefined’

　　Actor

　　‘’=‘Stickman’,‘Rectangle’,‘UserDefined’

　　Interface

　　UserDefined’

　　‘‘’=‘Rectangle’,‘Circle’,‘Lollipop’,

　　5. 13 附加语义信息

　　没有相应语义模型元素的 GraphElements被链接到 SimpleSemanticModelElement的子类 。 它的属性 typeInfo包含相关的 GraphElements的语义信息 。下面这些规则定义了如何使用 SimpleSeman- ticModelElement:

　　a) 一个框(Compartment) 在 UML 中一般没有相应的模型元素 ,但对 于 GraphNode是 可 见 的 。例如 ,一个属性的框的 GraphNode链接到一个 SimpleSemanticModelElement,用 typeInfoAt- tributeCompartment。对于一个操作的框它可以是 OperationCompartment等 。

　　b) 对于属性部分 ,表示 GraphElements被链接到一个 SimpleSemanticModelElement,这个 Sim- pleSemanticModelElement的 typeInfo 被置成属性的名称 。 例如 ,对于包 Core中类 Feature的属性可见性 ,typeInfo是可见的 。

　　c) 相对于 UML 图的名称 , 图有一个 typeInfo 集 。 例如 ,一个类图有 typeInfo ClassDiagram ,一个状态图有 typeInfo StateDiagram 等 。

　　13

　　GB/T 28174.4—2011

　　表 3列出了特殊 GraphElements表示元素 ,它们在 UML 中没有一个模型元素 。还包括它们相应的 typeInfos。

　　表 3 SimpleSemanticModelElement. typeInfo所允许的取值

　　图元素

　　SimpleSemanticModelElement. typeInfo

　　Active partofa lifeline

　　active

　　Cross atthe end ofa lifeline

　　destroy

　　Headerofalifeline

　　header

　　5. 14 表示 UML 中不同的图类型

　　图交换模型和 UML元模型可以用在表示任何 UML 图类型 ,通过一个语义链接到 UML元模型的图形 。对于大多数 UML 图类型 ,一个直觉的方式是把它们表示成一个图形 。但顺序图与上面的稍有不同 。

　　在一个类图中 ,举例来说 ,类 、接口和包被 GraphNode表示 , 而关联 、泛化和依赖则被 GraphEdges表示 。这些 GraphNodes和 GraphEdges链接到 UML元模型的相关的模型元素 。一个类可能会包含多种块 。它们通过类结点的嵌套的结点来表示 ,还有一个到 SimpleSemanticModelElement的链接 ,就像框不是 UML元模型的部件 ,只是它的表示的部件 。 一个属性或操作是框结点的一个嵌套结点还有一个到 UML元模型的相应属性或操作的链接 。一个属性本身有像可见性或类型的属性 。这些属性的部件被 LeafElements表示 。如果一个属性部件被表示成文本 ,则子类 TextElement被利用 ,否则一个 Image或 GraphicPrimitive被利用 。

　　边端的显示 ,例如一个关联端的组成类 、泛化 ,被相应的 UML元模型元素来决定 。

　　一种特殊的情况是 n-ary关联 。它包含了一个表示这个菱形的 GraphNode,这个 GraphNode链接这个关联的部件 。这些部件也被显示为 GraphEdges。 每一个都通过一个 SemanticModelBridge与相同的相应关联链接 。这意味着许多 DiagramInterchange模型元素(theGraphEdges)被利用于可视化 一个单一 UML模型元素(关联) 。 图 9显示了这种映射 。

　　图 9 n-ary关联

　　14

　　GB/T 28174.4—2011

　　其他图的表示方法也很类似 。用这个元模型的工具可以可靠地表示出表示语义模型元素的元素 。例如 ,这个工具应知道一个表示类的结点应该通过一个矩形可见 。 它的位置 、大小和线格式等 ,是由元模型的元素决定的 。

　　顺序图中的一个对象被建模为一个有到对应实例的有一个 SemanticModelBridge的 GraphNode。 GraphNode 的 高 度 是 从 生 命 线 的 顶 端 包 含 对 象 的 生 命 线 的 全 部 高 度 。 这 个 虚 线 的 生 命 线 是GraphNode 中唯一可见的元素 。GraphNode 中的包含的 DiagramElements是表示生命线的活动部分的 GraphNode。这样的 GraphNode有 一 个 有 typeInfo 活 动 的 相 对 的 SimpleSemanticModelElement。只有顶端 GraphNode 的一个子拥有一个相应的有 typeInfo头的 SimpleSemanticModelElement去表示生命线的顶端的矩形 。有 TextElement的 GraphNode嵌 套 在 GraphNode 中 。 顶 端 GraphNode 的 另一个子可以是一个 GraphNode去表示在生命线结束处的叉(见图 10) 。叉被 LeafElements表示 。在生命线间的箭头是有相应模型元素激发的 GraphEdges。这样的 GraphEdges的箭头不外在地建模 ,尽管箭头的类型可以从相应的动作中找到 。

　　图 10 顺序图

　　InteractionOccurrences可以交迭多种生命线和其他顺序图中的元素 。 为了显示交互事件下的元素通过 InteractionOccurrence是 可 见 的 , InteractionOccurrence 的 GraphNode 的 Translucent特 性 被置为 True。

　　5. 15 有端口和接口的构件

　　构件可以包含被要求或提供的端口和接 口 。 构件和它们包含的元素被表示为 GraphNode。 接 口或者包含在一个端口中如果它应该存在或者在构件本身中 。显示接口的圆是开或关由语义模型唯一确定 ,也就是说它依赖于接口是请求还是提供 。用有一个开或闭圆表示的接口区别于把 SemanticModelBridge的属性表示成 Iollipop 的 矩 形 接 口 。 GraphNode 的 表 示 成 Iollipop 的 接 口 包 含 作 为 Lollipop 的 线 的GraphEdges和一个作为圈的 GraphNode,见图 11。

　　15

　　GB/T 28174.4—2011

　　图 11 构件

　　6 表示视图的推导

　　6. 1 概述

　　用 XMI表达 ,一个模型可以在明白模型元素的工具间交换 。但是 ,这种格式对于读者来说不容易理解 , 同样不能很好适应纯面向图形的工具 。 因此一个向图形的转换是必要的 。最适合这个目的的格式是 SVG。在本部分中的格式对转化成 SVG 准备充分 ,并且设计得让这种转换尽可能简单 。 这两种格式 ,XMI和 SVG,是 XML 的应用并且 XML工具的一般集可以用来处理它们 。XSLT是一种用来转换一种 XML格式到另一 种 格 式 的 机 制 。 为 了 证 明 这 个 概 念 , 本 部 分 包 含 了 XSLT 脚 本 集 去 转 换 用XMI[UML+DI]给出的模型到 SVG。在当前阶段它只应用于关于信息的类图 。

　　正如下面段落所陈述的那样 ,这些样式表从有模型的 XMI文件和 DI数据摘录信息 ,并且建立一个新的 SVG文档 。得到的 SVG文件包含一个独立的类图表示 ,这种表示符合 UML 的符号规范 。

　　6. 2 描述类的转换概念 。 紧接着是讨论更高层样式表扩展的一条 。包含了 ,例如 ,怎样处理存储多个图的 DI文件 、转换到其他图类型的讨论 。样式表被设计为用小的改变处理不同的符号 。更多信息可以在最后一条中看到 。

　　6. 2 一般转换概念

　　应用 XSLT脚本的转换基于一套模板 。在实现中需要一个能匹配图交换文件中第一个类图的模板 。所有诸如模型数据的其他信息在其后被用来得到单一值如类或属性名(脚本:xmi2svg. xsl) 。

　　一旦类图被匹配 ,一个已命名的模板就被实现去产生标准元素的 SVG头 ,这种 SVG头可以复用于之后的图元素创建(脚本 :build_diagramm. xsl) 。

　　用 ,XSLT处理器将重复图中所有的子元素 。 这些子元素可以是诸如类或关联端的结点元素或 是 诸 如 关 联 或 泛 化 的 边 元 素 。 匹 配 这 些 元 素 的 模 板 可 以 在 build_ nodeelem. xsl和build_edgeelem. xsl中被找到 。

　　16

　　GB/T 28174.4—2011

　　模板 build_nodeelem. xsl和 build_edgeelem. xsl需要了解那些与匹配结点或边相关联的模型元素的类型 。为了得到这些信息 ,我们需要链接属性 。这些都由模板 util_modellookup. xsl完成 。

　　模型元素类型(例如类或泛化)作为环境去调用其他已命名模板来产生 SVG元素 。这些已命名模板在 build_class. xsl,build_assozend. xsl和 build_ edge. xsl中 。 它们都用 util_ modellookup去得到文本元素 ,例如将被表示的类或操作名 。

　　另一类需要提取的信息是在关联端的模型信息 ,如果一条边被这个图表示 。在这种情况下脚本为每个边末端调用一个查找行为并产生一个基于返回属性的 SVG元素 。例如 ,一个导航标志(navigable flag)被设置在边末端 。这将导致在其他边末端没有导航标志设置的情况下一个实心箭头的产生 。

　　用 SVG 中的元素表示一个边非常简单 。边的点坐标需要被写入路径元素的属性中 。 为了实现它 ,我们创建了一个匹配所有点并产生串的模板(util_createpath. xsl) 。

　　如前所述 ,所有产生 SVG 的信息可以从图交换或模型交换信息中得到 。相应元素的联接使为一般到 SVG 的转换写脚本变得容易 。

　　6. 3 样式表的扩充

　　在我们为了检验概念而开发 XSLT脚本的过程中我们想扩展脚本去实现下面的特性 :

　　a) 对其他图类型和未来接口的支持 。例如 ,包 、参数化类 、关联类和依赖元素(在 UML符号指南中我们列举了所有需要支持的元素) 。

　　这意味着模型查找程序可能需要为新模型元素类型和这些类型的处理程序进行扩展 。产生新元素的 SVG 图形化表示也可能需要额外的已命名模板 。

　　b) 对 XLink 的 支 持 。 在 当 前 的 执 行 中 一 个 模 型 和 图 交 换 元 素 的 联 接 只 有 通 过 应 用 简 单 的IDRefs才能成为可能 。 由于这个原因 , 只有包含模型交换和图交换数据的 XMI文件才可以被转换 。这是最终方案所不能被接受的 。

　　XSLT允许使 用 < xsl: for-eash> 命 令 (< xsl: for-eash select= “document (‘other-document.

　　xml’) ”)存取不同的文件 。至于对只涉及一个文档和 IDRef的特殊情况下的 XLinks 的支持 ,

　　一个执行可以利用 Xpath的串函数(stringfunction) 去提取链接信息 。 通过使用 XSLT 扩展

　　的 Xlink库 ,一个一般的 XLink 的解决是可 能 的 。所 有 需 要 XLink 支 持 的 模 板 可 以 在 util_

　　modellookup. xsl中找到 。

　　c) 最后但也是比较重要的一点是 , 我们需要支持包含多于一个图的文件的转换 , 这是最常见的情况 。

　　为了实现这样的扩充 ,可以实施以下解决方案中的一个 :

　　a) 一个参数化的仍然只提取一个图的脚本集是一个可选择的 。在不同的图中一个扩展应用控制这些脚本的调用 。一个参数选择提取的图 。

　　b) 应用了 XSLT扩展 ,可以实现产生多个输出文件 。根据这个特性一个对每个图的 SVG 文件可以被产生 。

　　c) 一个解决方案可以是动态 SVG,包含所有图和一个用户接口去在 SVG browser的图中切换 。

　　6. 4 转换到其他符号

　　为了检验概念我们只实现到一个定义在 UML符号指南中的图形表示的转换 。一般地说在描绘运算法则没有被要求的时候任何符号都可能被转换 。这允许建模工具提供 XSLT脚本 ,这些脚本用它们自 己的符号产生 SVG。例如 ,一些工具为类和对象画阴影或用颜色 。

　　17

　　GB/T 28174.4—2011

　　对于一个图元素位置改变的符号 ,renderer是需要的 。这个 renderer可能通过 XSLT 扩展连接到样式表 。但这种情况下 ,XSLT也不是最好的解决方法 。

　　下面的例子中我们试图去展示有不同符号的脚本改变起来是多么容易 。在这个例子中我们改变一个类元素的表示 。

　　对于类元素的产生来说脚本 build_class是必要的 。我们从样式表中提取出感兴趣的 :

　　〈rect height= {$height} width= {$width} style= fill:white />

　　〈g style= "fill:one;strok"(e):black; "(s)troke-with:1"> " "

　　〈xsl: if test= "$draw_attributes">

　　〈liey1= "{$Attrib_PartStart} "y2= "{$Atrib_PartStart} "x2= "{$width} "

　　style= fill:none;stroke:black;strokewidth:1 />

　　〈/xsl: if>