统一建模语言(UML)第4部分：图交换

统一建模语言(UML)第4部分：图交换

国家标准 GB/T28174.4一2011 统一建模语言(UML 第4部分:图交换 iminiedmodeinglamguage(UML)一Part4;Diagraminterchange 2011-12-30发布 2012-06-01实施 国家质量监督检监检疫总局 发布 国家标准花管理委员会国家标准

GB/T28174.4一2011 目 次 前言 引言 范围 规范性引用文件 附加信息 体系结构概览 元模型扩展 表示视图的推导 表示svG包元信息到svG图 S 附录A(资料性附录)指派图元素 21 附录B(资料性附录 -个XM1[D]例子的摘录

GB/T28174.4一2011 前 言 GB/T28174《统一建模语言(UML)》分为4个部分 -第1部分:基础结构; 第2部分:上层结构; 第3部分:对象约束语言(OCL); 第4部分图交换 本部分为GB/T28174的第4部分 本部分按照GB/T1.1一2009给出的规则起草 本部分参考面向对象工作组(oNMG)的《统一建模语言;图交换)2.0版 请注意本文件的某些内容可能涉及专利 本文件的发布机构不承担识别这些专利的贵任 本部分由全国信息技术标准化技术委员会(SAC/TC28)抛出并归口. 本部分起草单位;广东万维博通信息技术有限公司、北京大学、广东省广业信息产业集团有限公司、 电子技术标准化研究所 本部分主要起草人;江善东、黄孝和、杨三宝、吴炯祥、邓海强、胡红林、许立勇、周伟强、唐泽欢、 高健
GB/T28174.4一2011 引 言 统一建模语言(UML)是一种可视化规约语言,用于定义和构造计算机信息系统的制品,并将其文 档化 它是一种通用建模语言,可以和所有主流的面向对象和面向构件的方法一起使用.并适用于所有 的应用领域和实现平台(如;cORBAJ2EE、NET等》. 0.1统一建模语言不同版本之间的关系 由于UML的技术较新,所以该国际标准历经多次的版本演化,下面是UML在OMG的演化过程 1997 UML1.1 998 UML1.2 1999 UML1.3 2001 UML1.4 2003 UML2.0 GB/T28174的本部分正文中的UMI均指UML2.0统一建模语言和GB/T28174 0.2关于对读者的建议 需要了解语言中的元模型构造物,利用这些构造物进行元模型扩展或者是构造新的建模语言的用 户可阅读基础结构部分(GB/T28174.l) 应用系统建模用户和建模工具制造方都需阅读上层结构部分(GB/T28174.2) 但要注意,该部分 的内容是交叉引用的,可不按目次顺序阅读 对于要精确地对模型进行约束的应用系统建模用户或要支持对象约束语言的建枚工具制造方,需 阅读对象约束语言部分(GB/T28174.3) 支持在不同的软件工具间平滑且无缝地交换文档的建模工具制造方,需阅读图交互部分 关于本部分 0.3 本部分的目标是使在不同的软件工具之间对兼容UML标准的文档(以下称作UML模型)进行平 滑无缝的交换成为可能 它不仅包括用于开发UML模型的工具,也包括白板、代码生成器、字处理工 具、桌面发布工具等 同样的,对于作为交换和展现UML模型的媒介 -互联网,也要给予格外的 关注 已有的一种交换UML模型的机制,称为xML.元数据交换(xMMetadata lnterehange)(以下称 作XM[UML]),并没有完全达到模型交换的目标 最重要的是它没有包含图信息的交换 该机制仅 仅能够传递在一个UML模型中包含哪些元素的信息,但是没有这些元素在图中如何表现和布局的信 息 因此,如果tML模型存储在一个UM工具中而又被另一个不同的UML工具(或者甚至是同 个工具)用xMI[UMI]载人,那么所有的图信息就会丢失 这个局限性并不是xMI本身的错,而是由 于这样一个现实;UML.元模型没有定义一个标准方法来表现图的定义 本部分是用一个附加的面间图形信息的包来扩展UML元模型,同时完全保留当前UML元模型 的完整性 此外,它还兼容UML元模型,并且不被UML元模型后来的任何变化所影响 为了表示
GB/T28174.4一2011 UML图信息,一种兼容MOF的元模型被提出来,作为UML元模型的扩展,还允许扩展XM的DTD. 那么XMI就能够用来在各种各样的工具之间交换UMl模型而不丢失信息 为了保证需要交换的工具没有模型元素的概念而只有线,文本和图形,一种从XM到sVG的转换 机制被提出来 sVG是一种用来表示标量向量图形的基于XML 的格式,作为w3C的推荐被采用 由于对表示任何UM的图它都有良好的适应性,它将成为一种在各种各样工具(图形的,桌面发布的 等等)中普遍采用的格式,并且被创建得适合网络应用 结合其他的基础结构部分(GB/T28174.1l)和上层结构部分(GB/T28174.2)的严格定义,本部分 将使一种UML模型之间平滑无缝交换的机制成为可能

GB/T28174.4一2011 统一建模语言(UML) 第4部分图交换 范围 GB/T28174的本部分规定了用于对各类软件系统进行可视化、详述、构造和文档化的统一建模语 该语言也可用于对其他领域进行建模 言 本部分适用于在不同的软件工具间平滑且无缝地交换文档 这些工具可以是UML建模工具、代 码生成器,词处理工具和桌面出版工具等 本部分也可用作在因特网上交换和表示UML模型起媒介 作用的规范 图交换没有可选的兼容点 和图交换相兼容意味着和它的抽象语法、良构规则,语义、符号,还有 XM相兼容 指派图元素见附录A 规范性引用文件 下列文件对于本文件的应用是必不可少的 凡是注日期的引用文件,仅注日期的版本适用于本文 件 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 GB/T28174.1统一建模语言(UML第1部分;基础结构 GB/T28174.2统一建模语言(UML第2部分;上层结构 附加信息 3.1概念考证声明 本部分中提及的元模型已经用一套不同的图实现和测试了 提出的概念都是被证明过的 在整篇文档中使用并且在附录B中提供的例子,目前对它相应的XMI表示的转换更多是用手工而 不是自动完成的 然而,针对所提供的DTD,这个例子是有效的,并且使得用XSLT转换到svG成为 可能 3.2设计的基本原理 UML是一种强调图形化表示的面向对象软件系统的建模语言 它在整个软件开发过程中被部 署,并且在这个过程中有大量多种多样的工具可以使用 工具之间差别很大;存在变化很大的方法来设 计图、检查模型的一致性、存储模型用于永久存储或者版本管理,用于代码生成,用于准备文档、呈现或 者制定文档以及很多更多的应用 对这些多样的工具毫无问题地进行无缝使用和联合是非常有价值和令人期望的 因此，一种模型 信息的表示(从而包括交换)机制被包含在最初的标准中 尽管如此,UML1.x中安排的机制仅仅支持 在模型中元素的定义 虽然这对于检查模型一致性或者生成代码的工具来说是必要的,但这些信息面 向图形的工具来说并不够 因而就把广大利用图形信息的工具排除在外,其中也包括UMI工具本身 考虑到这方面,UMLl.x的模型交换机制就显得不足,而OMG则发现并满足了改正这一缺陷的需要 OMG内部用来传送元信息的一般实现机制是XM XMI是一个用它自己来传送内部非常有参
GB/T28174.4一2011 考价值信息的XML应用 面向对象的模型和这样模型的模型都属于这个类型,但都只是一个例子 XMI通过在具体的UML.元模型中应用XM的规则生成一个特殊的DTD,用来传送UML模型 为 了区别通常意义的XM和它针对UML的应用,在本部分中我们将把后者记作XMI[UML] 尽管图 形信息没有包含进来,这一机制也已经被证明是非常有用的 UML.图,正如UML模型,可以用元模型来描述 本部分为图信息提出了一个单独的元模型,它能 简单地作为一个独立的包加人到现有的UML元模型中 并且就像带有元模型的UML.xMI能够用 来传送这种图的元模型的实例 相应的DTD简单地扩展了XMI[UMI]的DTD)直接从元模型生成， 并且在本部分中也提供了 这种格式这里将记作XM[D] 两者的联合,组成了完整的模型交换机 制,将表示为XMI[UMl十D]或者简记为XMI 在当前的标准中,一个DTD被生成来描述XMI[UM]和XMI[D1]的部分 在未来标准中,可以 使用xLink来引用其他的模型元素,两个部分可以放在不同的文件中,允许为每个部分生成不同 的DTD 本部分中提及的元模型与MoF元模型工具一致 XM定义了如何从适合MoF的元模型创建 DTD或者模式,以及如何把它应用于XM1 因此一旦对一个适合MoF的元模型达成协议,就会考虑 到它在XMI中的表示和相应的DTD. 元模型本身由两个目标发展而来 首先,它应该灵活地扩展现存UML元模型(也包括将来的版 本)而不需要妨碍和修改它 同时它还应该携带尽可能多的多余信息,通过引用UML元模型来访问这 些信息 第二,它应该允许任何工具从得到的信息简单地描绘图 这当然包括UML工具,也包括网络 浏览器,办公套件、图形编辑器等 各种工具需求有很大的不同 UMI工具通常要能够用线条和文字本身来表现模型元素,而文本 编辑工具就完全没有模型元素的概念,只是需要一幅图以普通的图形形式出现 但图形工具就典型地 需要一种丰富的面向向量格式,用来做复杂的操作和缩放 svG,标量向量图形格式,是一种新的w3C标准,它承诺能够被广大的各种各样的工具所支持 它以XMI为基础,能很容易地读人、处理,以及转换成其他的多种格式 它同样适合文本工具、办公套 件和图形工具 此外它还适合即将直接支持它的网络浏览器(但是在这段过渡时期可以使用一个免费 的Adobe插件). 然而,sVG并不是一个很适合UM1工具的机制 UML工具并不只是需要线条和文本,它还需要 高层次的信息,因为它们不仅仅以图形方式显示图,它们还要求对用图形元语表示的模型元素有语义上 的理解 但是XM1的巨大优势之一就在于,只要所有需要的信息都被呈现出来,以一种XM数据格式表 示的数据能够很容易地转换成另一种不同的XML数据格式 因此本部分提出了一个用XMI[D]传送 的元模型和提供了一种用XSL.T从XM1[UML十D]到SVG的转换方法 这个方法满足了最广范 围内工具的需要 所有其他要用的格式都可以通过这个方法来产生 因此,通常用来表示附加信息以允许UML 中所有图进行交换的抽象(abstracetion)是什么呢? 个可选的方案是为组成UML图的每一种形状引人特殊的类,如果UML需要扩展,或者它的范围扩大 了,或者如果核心机制将被别的建模符号复用,这种方法就显得太不灵活了 图的交换不应该限制 UML的可扩展性 如果可能的话,图交换机制不应该有具体的形状或者其他元素的表示法 具体图 形状的画法是UML工具或者SVG描绘器的职责 可以发现UML中的大多数图符合从图形理论得出的图形模式:它们由结点(可能是矩形、椭圆、圆 或者其他形状)和边(连接结点之间的线,末端不同的箭头和形状)组成 结点可以包含分隔和图注;边 也能有附加的图注 有些结点能嵌套到其他结点中,带有连接两个结点的边(有的情况下这两个结点也 可以和边连接. 这种图形模式是功能强大的和能被很好理解的一种抽象,在可视化建模的很多领域都有应用 在
GB/T28174.4一2011 该标准中使用这种抽象是因为正像将要讨论的那样,它被证明是完全足够的 大多数UML图都有 个到图形的自然而直截了当的映射 类图用况图协作图、对象图、构件图以及部署图都是这种情况 在当前UML的形式下,只是顺序图没有这样到结点和边的自然映射,但还是能明显地发现一种映射 要讨论的是尽管基于图形的方法可能不是所有图类型显而易见的选择,但它适合于大多数,并且完全 足够表示任何现有的和将来的UML图类型 体系结构概览 概述 从XML[UM1]到XM1[UMI十D]的扩展使用了一些技术来创建它的元模型以及被提及模型的 示例对象 相关的技术已经被发布为oNG和w3C以及任何能够自由利用它们的人使用的标准 而 一过程中作为其他相关技术基础的基本技术,则是xMI 它由一些基本的规范组成(如良构规 在这 则),用来指导如何纠建文铛,及如何用标记来捕述它们的内容 这种广这接受的机制能跤世界上许多 工具所支持 4.2XM[DDTD创建概览 图1提供了一个在元模型和DTD创建过程中相关技术的概览 CaseTool XMdocument Supporting UMLandMOFprofie productionules UM儿L-Dlmetamodel XM[UML] UML-D1 metamodel Tanslateusing document MOFProfilenules XM[MOF] UM UML-DI XMDTD metamodel UML-D producionrues cdocument DTD 图1XMu[DDrD创建概览 XMI[D]元模型由UMI建模工具创建 利用这个工具,可以用UMI为MOF外廓创建一个符 合MOF的元模型,用来描述UML的M2扩展 为了和XYM的规范相一致,该工具需要有能力创建 xMI[UML]文档 这是一种满足xML所定义的规范文档,并且包含xMI[UML]DTD 这一步骤由 xMI文档产生规则来体现 正如刚才所提到的,它产生符合xMI的文档,并且包含在UML.工具的帮 助下创建的元模型的内容 为了给XMI[UML十D]生成新的DTD,新的M2应通过将XMI[UML]文
GB/T28174.4一2011 档翻译成XMI[MOF文档来表示成MOF的形式 从外廓到MOF的映射规则包含在MOF的UML 外廓中 另一个方案则是通过使用CASE工具直接生成XM[MOF]文档 最后,XMIDTD的产生规 则能够应用到M2的MOF描述中 运用这种为XML模式规范而出现的XM1产生规则,一个XML.模 式也能够被生成出来 以该扩展XM[UML+D]元模型为基础,现在就有可能在交换XMI[UML]模型的时候把图信息 包含进来 此外还能创建一些关于模型的描述 一个方案是用sVvG来创建这种描述 svG(标量向量图形,ScalableVectorGraphics)是一种用于描述向量化图形的技术,它以清晰文本 基于XM1的)格式描述向量化图形,并且在此之上产生出可视化效果 它由w3C发布为一种推荐格 式 与普通图形比较 比如位图格式 -svG使得对图形的缩放,旋转以及在该技术中对单个元素 的方法调用成为可能 它同样也能处理和用户之间的交互,这就为在基于svG的图形之上工作提供了 多个选择 w3Cc的另一推荐xsL.T(可扩展的样式表语言sxensible.siylehetlanwwge)定义了如何创建 为从一种XML文档到另一种(通常也是XML)文档的转换创建样式表(它们本身也是XMI文档) 在 这种情况下,样式表用来把包含UML模型和图信息的XMI[UML+D]XML文档转换为能够被浏览 器显示的包含完整图形翻译信息的sVGXML文档 注意,用来实现样式表驱动转换的XSLT引擎 通常在开放源代码中间是可用的Apaehe项目中的Xalan就是很显著的例子) 4.3sVG图形创建概览 图2提供了一个从UML建模工具创建sVvG文档过程中相关技术的概览 IM MLmodel productionules XSLT Browser xM[UM儿+D] SvG stylesheet document svGPugln UMl svGDTD UML-D1 DTD 图2SVG图形创建概览
GB/T28174.4一2011 由于在创建XM[D]扩展的时候,起点是用一种UML建模工具来描述一个模型 基于这个模 型,用XMI产生规范就能创建xXMI文档 结果又是该XM文档包含了所需内容,并且还包含了模型 的图形信息 -这一点和以往的方法不同 相对于XMI[UMI]DTD为了检查XM文档的语法正确 性而包含XMI[D]扩展.这种方法是很有效的 除此之外.良构规则也同样总是要检查 下一步是从 xMI的源文档创建svG文档 这个工作由xsL.T样式表完成,它只要产生一次就能够用于所有同时 包含模型和图信息的XM1文档 对XM1I[UML十D]源文档应用这种样式表就能生成sVG文档,而 sG文档又能够由sG查看器还原显示为图 使得通过翻译输人文档就能将模型可视化 多种不同 的查看器,其中包括一些因特网浏览器中的集成插件的存在使在浏览器中通过较高层的用户交互来观 察和操作UML图成为可能,并且这种交互可以设计得如同目前的UML工具一样直观和简便 元模型扩展 概述 本章描述了图交换机制所依赖的元模型 它是UM元模型的一个扩展 现有的用于模型交换的 XMI[UMI]机制只包含了模型信息而并没有包含图信息 图交换扩展则允许在UMI模型中用到的 图以图形化的信息包含进来 该扩展在现有UML元模型包中加人了一个新的包,但并没有改变现存的标准 同样,只要高层的 Eamen用于UML2. 稍所有基于通用枝心的 概念 Core::Element(用于UML1.x),Elements:: 元模型)继续保持,针对版本更新所做的UM1元模型更改也不会影响该模型 该扩展和UML元模型 很大程度上保持独立,使得从扩展模型到UML元模型的单独链接被包含进来 这样,图形化的和模型 的信息被清楚地分开了 此外,(该扩展)还避免了各种工具在对现有标准支持上的冲突,保持了完全的向后兼容性,并提供 了对未来UML 自身扩展的适应性 本部分包中包含了这样一些元素,它们能反映UML标准中任何一种图元素的图信息 具体工具 的扩展可以定义在附加的包里 比如说,如果工具增加了绘制额外形状的能力,那么可以提供一个附加 的包来描述这些能力 这样做的目的是,即使是不支持这些附加扩展的工具,也能够保证通过简单地忽 略掉那些来自附加包的信息来生成图形化的表述 图3描述了被提议的用来表述图信息的元模型
GB/T28174.4一2011 Property DiagramEiement 十key:Strng 十property 十isVisible:Boolean 0.本 十vaue:Sting 十contained iordered 0.,1 +containe 十graphEIement DiagramLink GraphEiement 0., +zoom:Double 十position:Point +link 十graphElement 十viewpot:Point +graphEiement1 o +diagramLnk +anchorage 0.本 GraphConnecor GraphEdae GraphNode tordered PosiionPoinmt 十waypointsorered[2.利:BezierPont +size[O.1]:Dimenson 十anchor +graphEdge Diagram semanticModel fname:String SemanicModeBndge +z0om.Doubie+diagramm presentaion:Srng +viewportPoint IoreSemanticModelBndoe Umi1SemanticModelBridge SimpleSemanicMoceEleen 0. +typelno:Sting +element 十element core:Eiement Elements:;Element +reference LeafEIement +leafReference GraphicPimitve LeatRelerence TextEement lmage 十uni:Strina 十position:Point 十text:Strng 十islndviduaRepresentation:Boolean 十size:Dimension fmimeTyPe:String StnctureType 《StructureType (StuctureType Point BezerPoint Dimension width:Double 十x:Double 十base:Point +y:Double +control1:Point +heioht.Double 十control2:Point 图3图交换元模型
GB/T28174.4一2011 5.2扩展图形模型 该元模型扩展的底层概念基于将UML 图看作图形来对其内容进行建模的思想 核心类是 GraphNode和GraphEdge 每一个可见的模型元素都由GraphNode或者GraphEdge来表现 图形元 素的基本类是GraphElement 图形元素通过一个叫GraphConneetor的类相互链接起来 这使得一个 GraphEdge类能够链接到一个GraphNode类或者另一个GraphEdge类 后一种情况是纯数学图形概 念上的扩展 GraphConnector类不允许两个GraphNode类互相链接 GraphElement类能拥有任意多个GraphConnector,这些GraphConnector被称作点 它们 允许任意数目的GraphEdge来链接 GraphEdge引用两个Graphconnector,它们是它的链接端 点 从GraphEdge的角度来看,这些称作锚 这两个GraphConnector作为相应GraphEdge的路点以 相同的方式排列,第一个GraphConnector对应第一个GraphEdge的路点,第二个GraphConnector对 应最后一个路点 这里并不强迫GraphConn nector 和引用它的GraphEdge的端点有相同的位置 当被多个 GraphEdge引用时,它就作为各个GraphEdge的虚拟连接点,例如,如在一个结点中间或是在另一个表 示结点的特殊点 所有带链接的GraphEdge都直接指向GraphConnector,然而它的路点则有可能,比 方说,被定义为带链接的结点图形边界的结束位置(图4) 读人这个信息的UML工具可能会把它解 释为裁减(clipping),这或许对更进一步的编辑有一些帮助 Edge Node .Connector 图4放射状边缘的GraphComnector示例 5.3嵌套 这种关联容器 包含物介于图形元素和图元素之间 组成了纯数学图形更进一步的扩展 它 允许构造层次化嵌套元素 每一个图形元素都能包含无限多个图元素,因此它可能包含整个子图 这 种嵌套层次在对复杂模型元素的表述进行建模时尤其有用 打个比方,类由GraphNode来表示,它又拥有嵌套的GraphNode,其中含有图元素,用来表示框,比 如,操作框、属性框等 这样用来表示框的GraphNode，如一个属性框,拥有更深层次嵌套的
GB/T28174.4一2011 GraphNode,其中包含用来表示属性的图元素 而属性的GraphNode又嵌套包含表示部分属性的图元 素,如可见性、名称,类型或初值等 图5展示了把一个简单类表示成嵌套图形元素的例子,这里的图形元素是GraphNode 为了表示 更复杂的类,需要包含更多嵌套的GraphNode class:GraphNode contained contained contained gperalonComparmentGraphNode arbuteCompartment.GraphNode nameCompartmentGraphNode' contained contained atrbute1:GraphNode attrbute2:GraphNode contained ontained vsibiltyGrapnNode initialVaue:GraphNode contained etTextElement 图5类表示中嵌套GraphElement的例子 5.4叶结点 图形元素的图形化表述很大程度上起源于语义模型(见后面),同时为了避免冗余并不显式地存储 在D模型中 比如说,把类画成一个矩形的知识并没有存储在D模型中 但注意,如果有必要的话 它的位置和大小要存储起来 绘图工具和xsL样式表应具有正确绘制这些元素的语义知识 叶元素可以表示有特殊可选表示方法的模型元素，比如参与者 如果一个表示参与者的 GraphNode拥有用户定义(见后面)的语义模型桥的表述,那么它应要有一个叶结点作为子结点 这个 叶结点表示了该参与者的可视化 叶元素可以是显示一段简单文本的文本元素，显示一个简单图形的图形原语(GraphicPrimitive). 如椭圆,也可以是一幅用来显示外部资源的图像 两个基本的专门图形原语是本部分的一部分;折线(Polylne)和椭圆 其他图形原语可以在额外的 包中定义并且可以从GraphiePrim ve类或其子类中继承 文本元素用来表示部分的属性、操作将名称 imiti 和模型元素的其他文本部分 比如说,一个属性的可见性就可以是一段文本,如“publie”或“” 这段 文本就存储在文本元素的text属性中 TextElement的容器GraphNode拥有一个到语义模型的链接、 emmanticModelElemen 该语义模型以简单语义模型元素SimpleSe nt)的形式出现 该链接指出了被引用 属性的部分 在这个例子中,简单语义模型元素的类型信息属性包含了可见性 属性的命名规则将在 5.13中描述 图6举例说明了所涉及类的相关部分 表示GraphNode名称的简单语义模型元素没在 图中显示
GB/T28174.4一2011 semanicModel brdoe.CoreSemantlcModeBrdoe atnibute.GraohNode anAtnibute:Atnibute element contained contained semanticModel semanticModelSimpeSemanticModelIEIement visibilit:.GraphNode name:GraphNode contained contained textextEement textTextEement 图6IextElement示例 如果可见性用一个图标来表示,TexEiue将被另 如果该图标是作 一个LeafElement所取代 为图像存储在另一个文件中,则LeafElement是一幅图像,该图像引用了那个文件 用到很多次的LaifElene只需要实倒化一次 这些LealElme直接被Dagam所包含 每次 用到这样的LeafElement时,一个该LeafElement的引用就被实例化,而不必拷贝一份LeafElement isIndividualRepresentation标记被设为true,用来区别于在后面描述的Reference的应用 这就避免产 生同一个可见成分的多个拷贝 图 5.5 5.5.1 概述 个特殊的结点是图(Diagram) 它是任何一个图形或图的顶层图形元素(GraphElement),递归 地包含所有其他的图形元素 一个图拥有一个名称和一个视(Viewpor 该视口是一个点,指出了 rt 这个图左上角的可见部分 它也有一个缩放的因子,允许视口以不同的比例显示 图的类型存储在 个简单语义模狸元素中,如状态图 图通过它的语义模狠(samnmsMode)来引用它 一个图形元衣 能够通过一个图链接(DiagramLink)链接到图 如果一个图形元素可以被其他图所表示,比如,在一个 更详细的层次上;或者如果该图形元素跟其他的图有特殊的语义关系,那么就可以使用这样的链接 图 链接拥有它自已的缩放因子和视口,所以每一个图能在各自的上下文环境中以不同的缩放因子和视口 显示 使用图链接的一个例子是状态图,它用来显示类的行为;或是类图,用来显示包的细节 图7通过对象图给出了图的一个简单例子 它显示了通过关联链接到一起的两个类的类图 图和 类通过GraphNode来表示,而关联则用GraphEdge来表示 该对象图也显示了GraphConnector在链 接GraphNode和GraphEdge中所扮演的角色
GB/T28174.4一2011 ClassDiagram1:Diagram contained contained contained Cass2:GraphNode Cass1.GrapNode anchorage anchorage anchor anchor GraphConnecor1GraphConnector Associaton1:GrephEdge GraphConnector2:GraphConnector 图7一个类图示例(仅描述了UML[D]的部分 5.5.2图的命名空间 通常UML的元素会被指派到一个UMI的命名空间.然而图元素则不用 只要图元素的语义模 型桥接(SemanticModelBridge)(见后面)引用了一个拥有命名空间的UML.元素,那么它就不需要命名 空间 如果不是这种情况,它周围作为容器的图元素会拥有一 个命名空间 尽管如此.这个规则还是有 -个例外:图没有命名空间并且也没有包含它的图元素,因为它自己就是顶层容器 因此,图也需要一个命名空间 图的命名空间通过语义模型桥接被语义模型的一个命名空间元素 的引用所指派 从图那里通过这种方式引用的元素应是Namespace的一个子类 5.5.3在一个图中显示另一图的剪切图案 -个图可能被用来显示从另一图中摘取的部分,而不必多次创建要用到的图死素 比如说,为了得 到更好的表示效果，一个大的图可以通过几个小一些的图来表示 为了达到这样的目标,大的图要拥有 所有它的包含在内的图元素,同时那些剪切出来的图只要包含对原来的图元素的引用 在一个被引用 指向的、剪切出来的图中,只有这些图元素才被显示 引用和单独的图元素可以在同一个图中独立被 使用 图元素的可见性 5.5.4 可见性(isbe)这个属性指明了一个图元素是不是正在被显示 在所有包含的图元素中,它的值 被递归地应用 只要在该递归层次中有一个图元素把它的这个属性设为false,那么不管它们原有的可 见性如何,所有嵌套的元素也都隐藏了 当 一个隐藏元素不被显示时,它仍然存在 这就意味着如果它由于该属性值被设为true而显示. 那么该元素将和从前一样以相同的方式出现 这就提供了一个轻松的方法来使一个框compartment) 谈出,比如当保持它的表示时 这使得一个先前隐藏的图元素稍后再次显示变得容易了 5.6性质 图元素的出现是用性质加以指定的 性质可以添加到DiagramElements,在不同方面影响它的出 现 表1定义了一个可选择性质的标准集;它包含了字体、大小、线的格式,粗度和颜色 每个性质都覆 盖了任何一个和它相同的封装了的GraphElement的已经存在的性质 如果一个性质没有被设置,那 么DiagramElements就利用它的容器GraphElement所包含的性质 非标准的性质可以被添加但不属 于任何标准化 性质为添加非标准的元素到图交换元模型提供了一个扩展机制 10
GB/T28174.4一2011 标准性质 关键字 城 举例 描述 Times’,*courier FontFamily fontname string FontSize double 1 fontsizeinpixel LineStyle solid','dotted” linestyle string LineThickness double linethicknessinpixel FontColor， 24-bitcolorvaluein ForegroundColor integer FF00FFformagenta RGBformat BackgroundColor Translucent boolean true.false seetext GraphElemen的性质Translucent 被设置为True是为了指出它们包含的元素通过包含的 DiugamElements的背景可见(见顺序图 5.7坐标系 在图交换扩展关系应用的坐标系统定义工轴指向东、y轴指向南 位置和大小通过两个值来定义 它们利用像素来作为度量单位 浮点型double允许低像素的精确度 这防止了当度量转换或其他图 操作时产生可能的信息丢失 5.8位置 -般来说,这个模型的所有的位置值都是相关的,也就是图元素的所有位置值都和它周围的容器相 关 这意味着这个容器的位置是所有子的位置的原点 为了得到一个图元素的绝对位置,应递归地从 容器GraphElenment到没有容器的GraphElement,根就遇到了 根结点应是一个图,因为只有图没有 容器 GrphElemen的位置是由sireturcType点来指定的 它指定了一个GaphNwde或Diagram的 左上角的位置 一个位置的r,》坐标可以为负值 nEler 对于GraphEdge,位置为所有包含的Diagram ements提供了一个原点 因为一个GraphEdge是 通过它的路点(waypoint)来定义的,所以位置不影响GraphEdge本身的图形表示 通过它的所有路点 贝塞尔点的一种类型)把它画成贝塞尔曲线 控制点被定义成相关于基本点 因此如果所有的控制 点都是(0,0),结果就是一个简单的多边形线 -个图不需要有一个环境容器元素 它的位置缺省值为(o.o) 视口指定了图巾当前显示视图的 左上角坐标 视口如果被卷动则它不再是(O,0). 相对坐标允许层次嵌套结点可以通过改变根结点的位置来被轻松地移动 例如,想移动一个类,可 以用改变表示这个类的GraphNode的位置来实现 所有包含的图元素自动和这个类一起移动,因为它 们的位置和它相关 5.9大小 对于GraphNode,可选择的大小可以用DataTypeDmcnsion来提供,它包括了类型为dowble的宽 和高 这些都不允许为负值 如果大小没有被提供,则它由它的语义模型租GrnphNodl中的嵌套 DiagramElements来决定 考虑下面两种情况 11
GB/T28174.4一2011 如果语义模型显示对GraphNode的图形表示是需要的，它的大小应由嵌套的 a DimElenes计算出来 例如,如果来给出，表示一个类的GphNal的大小应被递归 地检查外面包含的层数来决定 如果一个框的大小没有给出,那么它包含的DiagramElements. 例如属性,应被分析等 如果语义模型指定一个没有图形表示或有一个固定的图形表示的语义模型的Ele b ements 计算也是不需要的 这种情况的例子是关联端(AssociationEnd) 举例来说,尽管包含多 样性TextElements和任务名的GraphNodes也许会嵌套在这样一个GraphNode中,但 AssociationEnd的GraphNode本身没有大小 -它只被用作容器 就算AssociationEnd是 可见的,例如一个实心的菱形来表示组合,它也被考虑为一个固定的图形表示,所以没有 长度 5.10描绘顺序 -般的图元素顺序描绘是通过如下两个机制来定义的: GraphElement中D)agramElenments的嵌套树优先级最高 为了描绘DiagramElements,用- a 个前序遍历来处理树 这意味着一个路径最深层嵌套的DiagramElements被最后画,所以被 显示在z-order的顶端 指定了这个相同 b mElements之间 顺序关联容器 和Dhagan -包含在GraphElemt entS GraphElement中包含的DagramElements的表示顺序 第一个DagranmElement先画,第二 个其次,等等 还有一种不常见的情况中只用这种直接表示的概念就不够了 利用LeafElements去充实一个图 这些元素不属于UML 为多个GraphElement显示这样一个作为背景的LeaElement、可能会有用 这种情况的一个例子是一张图像上画的椭圆 这个椭圆包含两个不同包a、b中的类a,b,所以被画在 这两个包的上方 图8显示了这种情况 packagea package_b CassA ClassB rompackagea trompackageb 图8一个包含DiagramElements的树的两条路径的椭圆 不可能用以上描述的两种机制来表示图8,因为任何DigramEements,比如这个图像,也许仅仅 是DiagramElements的树的一个单一路径的部件 为了用这种方法显示出来,它应是两个路径的部 件 为了达到这个目的,利用了Reference 这个图像被包含在D)iagranmElenment的一个单一路径中 如果它想显示其他任何路径,包含了Reference 它的指向图像的参考指示它是两个路径的部件从而被 表示 12
GB/T28174.4一2011 5.11 语义模型 图交换元模型允许图用一个增加的语义内涵来表示,方法是通过抽象的语义模型桥接来链接一个 存在的语义模型的元素 每个GraphElement有一个到sSemanticModelBridge的具体子类的链接 如 果不是一个simpleSemanticModelElement,则它参考链接的语义模型的最高层父类 注:在UML1.x中这是包Core的一个类Element,它用UML1SemanticModelBridge为参考 对于UML2.0和其 后版本,这可以是包Kernel的类Element,用CoreSemanticModelBridge作参考 这个链接允许添加UML指定 信息到图形 其他的语义模型也可以添加,例如,ER图 设计这个模型是为了减少冗余的信息 出于这个动机,没有作更多的努力去显示元素的语义类型 为了知道一个元素的语义模型,应检查SemanticModelBridge 如果这个具体子类有到语义模型的元 素的链接,所有可用的关于这个元素的语义信息都可以得到 5.12元素的预定义表示 有些元素允许有多于一个的标准表示 例如,一个参与者可以显示为一个矩形或一个棒棒人形 on"定义在SemantieModelBrdg指的是所要求的表示 这避免了 为了区分这些情况,属性“pre sentatior 去创建复合DiagramElements,比如图像去显示标准元素 为了使一个元素标准可见,表示应被设置成“”,即空串 对于非标准的处理,它应被置成“UserDe fined” 这意味着它通过关联在元素的GraphElements中的DiagramElements来指定,严格地显示出 来 因为绝大多数元素只有一个严格的标准表示,表2只列举了那些明确包含一个以上的 其他的我 们收集在条款[SinglePresentation]下面 表2semanticModelBridge表示的允许的值 元素 SemanticModelBridge.presentation (Deault),'UserDefined Smele Presentation Siekman','Re eetangle',UserDfned' Actor ‘Rectangle','Circle','L.olipop” Interlace *UserDefined” 附加语义信息 没有相应语义模型元素的GraphElements被链接到SimpleSemantieModelElement的子类 它的 属性typelno包含相关的GraphElements的语义信息 下面这些规则定义了如何使用SimpleSeman ticModelElement 个框(Compartment)在UML中一般没有相应的模型元素,但对于GraphNode是可见的 例如,一个属性的框的GraphNode链接到一个SimpleSemanticModelElement,用typelnfoAt tributeCompartment 对于一个操作的框它可以是OperationCompartment等 对于属性部分,表示GraphElements 被链接到一个SimpleSemantieModelEement.这个sim leSemanticModelElement的typelnfo被置成属性的名称 例如,对于包Core中类Feature 的属性可见性,typelnfo是可见的 相对于UML.图的名称;图有一个vyiah集 例如，一个类图有ypalaochaDohuwram 等 个状态图有ypelnlo.siaDiugm 13
GB/T28174.4一2011 表3列出了特殊GraphElements表示元素,它们在UML中没有一个模型元素 还包括它们相应 的ypenfos 表3SimpleSemanticModelElement .typelnfo所允许的取值 图元素 SimpleSemanticModelElement.typelnfo Aetivepartofalifeline active Crossattheendofalifeline destroy Headerofalifeline header 5.14表示UML中不同的图类型 图交换模型和UML元模型可以用在表示任何UML图类型,通过一个语义链接到UMI元模型的 图形 对于大多数UML图类型，一个直觉的方式是把它们表示成一个图形 但顺序图与上面的稍有 不同 在一个类图中,举例来说,类,接口和包被GraphNode表示,而关联、泛化和依赖则被GraphEdges 表示 这些GraphNodes和GraphEdges链接到UML元模型的相关的模型元素 一个类可能会包含 多种块 它们通过类结点的嵌套的结点来表示,还有一个到sSimpleSemanticModelElement的链接,就 像框不是UML元模型的部件,只是它的表示的部件 一个属性或操作是框结点的一个嵌套结点还有 个到UMI元模型的相应属性或操作的链接 一个属性本身有像可见性或类型的属性 这些属性的 部件被LeafElements表示 如果一个属性部件被表示成文本,则子类TextElement被利用,否则一个 lmmage或GraphicPrimitive被利用 边端的显示,例如一个关联端的组成类,泛化,被相应的UM1元模型元素来决定 -种特殊的情况是n-ary关联 它包含了一个表示这个菱形的GraphNode,这个GraphNode链接 这个关联的部件 这些部件也被显示为GraphEdges 每一个都通过一个SemantieModelBridge与相 同的相应关联链接 这意味着许多Diagranmlnterehange模型元素(theGraphEdges)被利用于可视化 个单一UM1模型元素(关联) 图9显示了这种映射 Connectors GranhNode GraphEdgcs 图9 naury关联 14
GB/T28174.4一2011 其他图的表示方法也很类似 用这个元模型的工具可以可靠地表示出表示语义模型元素的元素 例如,这个工具应知道一个表示类的结点应该通过一个矩形可见 它的位置,大小和线格式等,是由元 模型的元素决定的 顺序图中的一个对象被建模为一个有到对应实例的有一个SemanticModelBridge的GraphNode GraphNode的高度是从生命线的顶端包含对象的生命线的全部高度 这个虚线的生命线是 GraphNode中唯一可见的元素 GraphNode中的包含的DiagranmElements是表示生命线的活动部分 的GraphNode 这样的GraphNode有一个有typelnfo活动的相对的SimpleSemantieModelElement 只有顶端GraphNode的一个子拥有一个相应的有typelnfo头的simpleSemanticModelElement去表示 生命线的顶端的矩形 有TextElement的GraphNode嵌套在GraphNode中 顶端GraphNode的另 一个子可以是一个GraphNode去表示在生命线结束处的叉(见图10) 叉被LeafElements表示 在生 命线间的箭头是有相应模型元素激发的GraphEdges 这样的GraphEdges的箭头不外在地建模,尽管 箭头的类型可以从相应的动作中找到 GraphNodewit SinmpleScmantic biee ModelElement ypeinfo=,header create objectB GraphNodewith SemanticModelBrdge mesSage GraphNodkewith SimpleSemantiec returm ModelElemenmt ypenfo-,actve destroy 图10顺序图 nteractionOecurrences可以交迭多种生命线和其他顺序图中的元素 为了显示交互事件下的元 素通过InteractionOccurrence是可见的,lInteractionOccurrence的GraphNode的Translucent特性被 置为True. 5.15有端口和接口的构件 构件可以包含被要求或提供的端口和接口 构件和它们包含的元素被表示为GraphNode 接口 或者包含在一个端口中如果它应该存在或者在构件本身中 显示接口的圆是开或关由语义模型唯一确定 也就是说它依赖于接口是请求还是提供 用有一个开或闭圆表示的接口区别于把SemantieModelBridge的 属性表示成Iolpop的矩形接口 GraphNde的表示成Iolpop的接口包含作为Lolpop的线的 GraphEdges和一个作为圈的GraphNode,见图11 15
GB/T28174.4一2011 eneertenthNoe contained port:GraphNode contained ntertace.GrapNode contained contained intertaceCircle:GraphNode intefaceLne.GraphEdge 图11 构件 6 表示视图的推导 6 概述 用XMI表达,一个模型可以在明白模型元素的工具间交换 但是,这种格式对于读者来说不容易 理解,同样不能很好适应纯面向图形的工具 因此一个向图形的转换是必要的 最适合这个目的的格 式是SVG 在本部分中的格式对转化成SVG准备充分,并且设计得让这种转换尽可能简单 这两种 格式,XM和sVG,是XML的应用并且XML工具的一般集可以用来处理它们 XSLT是一种用来转 换一种XML格式到另一种格式的机制 为了证明这个概念,本部分包含了XSLT脚本集去转换用 XMI[UML十D]给出的模型到sVG 在当前阶段它只应用于关于信息的类图 正如下面段落所陈述的那样,这些样式表从有模型的XM1文件和D1数据摘录信息,并且建立一个 新的sVG文档 得到的svG文件包含一个独立的类图表示,这种表示符合UMI的符号规范 6.2描述类的转换概念 紧接着是讨论更高层样式表扩展的一条 包含了,例如,怎样处理存储多 个图的D文件、转换到其他图类型的讨论 样式表被设计为用小的改变处理不同的符号 更多信息可 以在最后一条中看到 一般转换概念 6.2 应用XsLT脚本的转换基于一套模板 在实现中需要一个能匹配图交换文件中第一个类图的模 板 所有诸如模型数据的其他信息在其后被用来得到单一值如类或属性名(脚本;xmi2vg.xsl). -旦类图被匹配,一个已命名的模板就被实现去产生标准元素的svG头,这种svG头可以复用于 之后的图元素创建(脚本:builddiagramm.xsl). 用(apply-templates),xsL.T处理器将重复图中所有的子元素 这些子元素可以是诸如类或关联 端的结点元素或是诸如关联或泛化的边元素 匹配这些元素的模板可以在build_nodeelem.xsl和 build _edkgeelem.xsl中被找到 16
GB/T28174.4一2011 模板bwild_nodeelem.xsl和buildLedlgeelem.xsl需要了解那些与匹配结点或边相关联的模型元素 的类型 为了得到这些信息,我们需要链接属性 这些都由模板utilL_modellookup.xsl完成 模型元素类型(例如类或泛化)作为环境去调用其他已命名模板来产生sVG元素 这些已命名模 板在buildelass.xsl,build_assozend.xsl和build_edge.xs!中 它们都用util_modelookup去得到文 本元素,例如将被表示的类或操作名 另一类需要提取的信息是在关联端的模型信息,如果一条边被这个图表示 在这种情况下脚本为 每个边末端调用一个查找行为并产生一个基于返回属性的sVG元素 例如，一个导航标志(navigable lag)被设置在边末端 这将导致在其他边末端没有导航标志设置的情况下一个实心箭头的产生 用svG中的(path)元素表示一个边非常简单 边的点坐标需要被写人路径元素的属性中 为了 实现它,我们创建了一个匹配所有点并产生串的模板(utilcreatepath，xsl 如前所述,所有产生svG的信息可以从图交换或模型交换信息中得到 相应元素的联接使为一般 到sVG的转换写脚本变得容易 6.3样式表的扩充 在我们为了检验概念而开发XSLT脚本的过程中我们想扩展脚本去实现下面的特性 a)对其他图类型和未来接口的支持 例如,包、参数化类,关联类和依赖元素(在UML符号指南 中我们列举了所有需要支持的元素) 这意味着模型查找程序可能需要为新模型元素类型和这些类型的处理程序进行扩展 产生新 元素的svG图形化表示也可能需要额外的已命名模板 对XLink的支持 在当前的执行中一个模型和图交换元素的联接只有通过应用简单的 1DRefs才能成为可能 由于这个原因,只有包含模型交换和图交换数据的XM1文件才可以 被转换 这是最终方案所不能被接受的 xsLT允许使用xsl:for-eash》命令(xsl:for-eashselect=“doeument(‘other-doeument. xml')”)存取不同的文件 至于对只涉及一个文档和IDRef的特殊情况下的XLinks、的支持， 一个执行可以利用Xpath的串函数(stringfunction)去提取链接信息 通过使用XsL.T扩展 的XIink库，一个一般的XLink的解决是可能的 所有需要XNLink支持的模板可以在util modellookup.xs!中找到 最后但也是比较重要的一点是,我们需要支持包含多于一个图的文件的转换,这是最常见的 情况 为了实现这样的扩充,可以实施以下解决方案中的一个 一个参数化的仍然只提取一个图的脚本集是一个可选择的 在不同的图中一个扩展应用控制 a 这些脚本的调用 一个参数选择提取的图 应用了XSLT扩展,可以实现产生多个输出文件 根据这个特性一个对每个图的sVG文件 可以被产生 -个解决方案可以是动态SVG,包含所有图和一个用户接口去在svGbrowser的图中切换 6.4转换到其他符号 为了检验概念我们只实现到一个定义在UM符号指南中的图形表示的转换 一般地说在描绘运 算法则没有被要求的时候任何符号都可能被转换 这允许建模工具提供XSLT脚本,这些脚本用它们 自己的符号产生sVvG 例如，一些工具为类和对象画阴影或用颜色 17
GB/T28174.4一2011 对于一个图元素位置改变的符号,renderer是需要的 这个renderer可能通过XSLT扩展连接到 样式表 但这种情况下,XSLT也不是最好的解决方法 下面的例子中我们试图去展示有不同符号的脚本改变起来是多么容易 在这个例子中我们改变一 个类元素的表示 对于类元素的产生来说脚本build_class是必要的 我们从样式表中提取出感兴趣的 style="fll:;none;stroke:black;stroke-width:l" g rectheight="$height)"width="$width"style="f11ll;hite"> xsl:iftest="$drawattrbutes" 1ineyl $AttribPartStart}"y2="$AttribPartStart)"x2="$width)" style="fill:none;stroke:black;strokewidth:l1" /xsl;if》 xsl:iftest="$drawoperations" 1ineyl="$OperationPartStart)"y2="$OperationPartStart}"x2="$width)" style="fll:;none;stroke:black;stroke-width:1" /xsl:if》 /g》 通过这个代码,类看起来就像是在UML符号指南中定义 用水平线分割的有三个块的实线矩形 用一个svGbrowser可看见 <> Order 十getTotalSum0;:int +GetVAT0 代码做一个小变动,有阴影和圆的边就可见了 -"fill:none;stroke:black;stroke-width:1" gstyle一 rectx="2" "2"rx="4" ""height="$height)"width-"($width)"style=- y ry= "fll 1:grey (rectr又一""y-""heigpht-"($ieigitt)"width-"($width)"style-"f1;ehite" "sdra xsliftest attributes" '1$Attrib_PartStart)"y2="($Attrib_Partstart)"x2="($width)"style- (1ineyl一 "fll;none;stroke;black;strokewidth: /xsl:if》 xsl:iftest="sdra rations" aw_oper aneH-"(8opes ation_Partstart)"y2="($Operation_PartStart)"x2="$width)" style="fll;none;stroke:black;strokewidth: /xsl:if》 18
GB/T28174.4一2011 <> order 十getTotalSum0:lnt 十getVATo 表示svG包元信息到svG图 7.1概述 本章给出了一个图交换元信息怎样用一个产生的sVG文件表示的概览 在UML符号定义中,一个类图是一个类目元素的图形,用它们的不同静态关系连接 在实现中 这包括类、关联和泛化 在产生的sVvG文件中这些元素的每个都被一个组表示 一个组没有图形表示 但用来包含一个模型元素的图形元素 例如,一个类组包含矩形,文本元素和线 根据符号指南,一个类被画为用水平线分割的有三个块的实线矩形 7.2svG --ClassPosition-- tye- "onclick= font-size:9;font-family:dial log" g onmousemove="removePopup classclickevt,'classPosition'" transform="translate(184,458)" gsty1le="fill;none;stroke:black;stroke-width:l1 rectstyle="fil1;hite"width="s8"height="61" "f11 :1"x2="88"y2="20"y="20") 1inestyle= 1;none;stroke:black;stroke-width:l "fill;none;stroke;black;stroke-width;1"x2="88"y2-"41"yl-"41") 1inestyle --tOpnamecOmpartment-- textstyle="text-anchor:middle"dx="88"dy="g")Position(/text -attributecompartment transform 0,20)" translate "2"dy="g" #(tspanx="12")posnum( text 19
GB/T28174.4一2011 顶端的名称框包含类名称和衍型 类名称和衍型在名称框的中间 衍型值从模型中得到并封装在 )中 为特殊衍型和一系列性质添加的图标不被我们现在的xsLT脚本支持,可从一个扩展的图标得 到这些信息,这个模型简单 在我们的实现中只有属性和操作框被显示,但没有限制去扩展有意外或要求的框的表示 如果框 的属性hidden被设置,这个框将没有元素被产生在SvG文档中 个属性框表示为一系列属性 我们决定不去显示一个框名称或组性质 这种表示可以在多数 UML工具中找到 不只是顺序还有图形位置和属性的可见性都从图交换数据中取出 属性可见性记 号,名称,类型和初始值在sVvG文档中被表示 每个属性都被压缩在单独的sVvG文本元素中 int e井posnm Example sVG;(textdx="2"dy="g")#《tspanx="12")posnum《/Espan>;int(/text) 操作框的svG表示的实现与作为一系列文本元素的属性框很像 每个文本元素包含操作可见性 名称、一系列括号中的参数和返回类型,定义在符号指南 Example:getPosnum SVG:〈textdx="2"dy="9")十〈tspanx="12")getPosnum(/Espan)()(/text 除了我们决定的类元素以外,为了检验概念,为了表示关联和泛化去显示如何处理路径元素 路径 包含一系列线段 关联和泛化是有一个可选择附上的名称和在路径端的特殊记号的路径 在我们当前实现中的XsLT脚本中的关联,允许表示导航性(navigability)和聚合指示器 像角色 名和多样性一样的文本的元素为每个关联端压缩在一个组里 这个组只包含由图交换信息提供的文本 元素 我们定义svG元素并把它们用在聚合记号,适航性(一个箭头)和泛化(大空心三角) 这些元素可 以被复用在任何关联或泛化端,只迫使一个旋转角可以通过它们所在的最后一段的方向计算出来 为 了实现它,我们需要一个xsLT扩展去计算平方根,这些用xPath表达式和xsLT方程是不能算的 在本条我们决定在定义的UML符号指南中怎么表示svG的类图 我们已经应用组机制去包含 属于相同模型元素的图元素 这允许我们增加特性,例如工具条,在类中,显示在sVvG浏览器中 20
GB/T28174.4一2011 附录 A 资料性附录) 指派图元素 表A.1基于对于UML.2.0上层结构(见GB/T28174.2)的内容 它描绘了GraphNode或 GraphEdge表现了哪些元素 对于有更复杂表示的一些元素,嵌套元素被放进括号“[]” 表A.1基于对于UM12.0上层结构(见GB/T28174.2)的内容 图 元素 图元素 GraphNode ActionOccurrence Interaction GraphNode UseCase Actor Aggregation GraphEdge Class/Package/Objeet Artifaet GraphNode Deploymment Association GraphEdge Class/Package/Objecet Class GraphNode Class/Package/Object Clas5template Class/Pa0 ackage/Objyeet GraphNode Collaborationm raphNode Gt Composite CollaborationOccurrence GraphNode Composite CombinedFragment GraphNode Interaction Componenmt GraphNode Component ComponenthasPort GraphNode[GraphNode Component GraphEdge Class/Package/Objeet Composition GraphEdee Connector Composite ConneetorAssembly GraphEdge[GraphNode Component Coregion GraphNode lnteraction Dependeney GraphEdge Class/Package/Object Dependeney GraphEdge Deployment DeploymentSpecification GraphNode Deployment Extend UseCase GraphEdge ExtensionPoint UseCase GraphNode GraphNode FinalState State Frame GraphNode lnteraction Generalization GraphEdge Class/Package/Objeet Generalization GraphEdge Deployment GeneralOrdering GraphEdge Interaetion Include UseCase GraphNode Paekge/Oget lnstanceSpecification Class/ GraphNode 21
GB/T28174.4一2011 表A.1(续 图 元素 图元素 Instantiation GraphEdge Deployment GrapNode lnteraction(Occurrence lnteraction nterlaee GraphNode Class/Package/Object Lifeine GraphNode Interaction Message GraphEdge nteraetion Node GraphNode Deployment Package GraphNode Class/Package/Ojeet Class/Package/Objecet PhaekaeExension raphEdge Packagelmport(private/publie) Class/Package/Objeet GraphEdge Part GraphNode Composite Port GraphNode Component Realization GraphEdge Class/Package/Object Rolebinding GraphEdge Composite State State GraphNode GraphNode Stop lnteraction Transition GraphEdge State UseCase GraphNode UseCase 表A.2中列举了没有在UM1元模型中被建模但在图中有明确表示的图元素 它们在SimpleSe mantieModelElement中用它们的typelnfo来区分 表A.2没有在UML元模型中被建模但在图中有明确表示的图元素 SemanticModelElement 图元素 -yento NameCompartment (GraphNode AttributeCompartment GraphNode OperationCompartment GraphNode Diagram ClassDiagram,StateDiagram, Name GraphNode Ybiy GraphNode 入 GraphNode eSeparator ype lnitialValue GraphNode Multiplieity GraphNode Ordering GraphNode lnterfaceCircle GraphNode lnterfaceline GraphEdge 22

统一建模语言(UML)第4部分：图交换GB/T28174.4-2011探析

在软件开发过程中，不同的团队或个人可能会使用不同的建模工具来绘制UML图。这些工具可能包括Visio、Rational Rose等。然而，由于每个工具都有自己的特点和格式，不同工具之间的图形文件并不通用，这给团队协作和系统集成带来了很大的麻烦。

为了解决这个问题，UML引入了图交换机制。图交换是指通过定义一种标准的图形文件格式，使得不同的建模工具可以相互读取和编辑图形文件，从而实现互操作性。

GB/T28174.4-2011标准就是针对图交换机制的规范。该标准定义了一种图形文件格式XMI（XML Metadata Interchange），用于表示UML模型和相关信息。XMI使用XML格式，并且可以与其他建模工具的数据交换格式进行转换。

通过图交换机制，我们可以将不同建模工具中的UML图互相转换，实现跨平台、跨工具的图形共享。这对于团队协作和系统集成都非常重要。同时，由于GB/T28174.4-2011标准的引入，使得图交换的过程更加规范化和标准化，降低了不同建模工具之间的兼容性问题。

总之，图交换是UML中的一个非常重要的机制，它可以实现不同建模工具之间的互操作性，从而提高团队协作和系统集成的效率。GB/T28174.4-2011标准为图交换机制提供了规范化和标准化的支持，有助于解决建模工具之间的兼容性问题。

统一建模语言(UML)第4部分：图交换的相关资料

和统一建模语言(UML)第4部分：图交换类似的标准

GB/T28174.4-2011

统一建模语言(UML)第4部分：图交换

2022/10/25 22:38:18 现行

GB/T28174.3-2011

统一建模语言(UML)第3部分：对象约束语言(OCL)

2022/10/25 22:19:48 现行

GB/T28174.2-2011

统一建模语言(UML)第2部分：上层结构

2022/10/25 22:01:18 现行

GB/T28174.1-2011

统一建模语言(UML)第1部分：基础结构

2022/10/25 21:42:32 现行