UML2.0完全建立在UML1.x基础之上，大多数的UML1.x模型在UML2.0中都可用。但UML2.0在结构建模方面有一系列重大的改进，包括结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力的增强。当然还有时序框图，但如果你不使用这些功能，也就不用担心这些特性，因为仅使用类框图、顺序框图和状态框图仍可建立非常复杂的实时嵌入式系统。

在UML(统一建模语言)2.0规范中存在4种有关的请求建议(RFP)文件：基础设施(Infrastructure)、对象约束语言(OCL)、元数据交换(XMI) 和超级结构。基础设施RFP涉及UML的定义基础以及与OMG的元对象设施(MOF)的对齐。OCL RFP文件涉及对OCL的改善。实际上， 除了那些定义UML的人员之外， 很少有用户需要使用OCL。 XMI RFP文件定义了一种交换语义模型信息的格式， 但它目前没有指定如何交换框图表。XMI RFP文件则提出了改善定义交换框图表的XMI的建议。

虽然这3个RFP文件非常重要，也很有用， 但它们主要由元模型构建人员(例如定义UML的人员)和UML工具供应商使用。第4个， 也是最后一个RFP――超级结构， 是大多数用户所关注的，这些用户构建实际模型，并建立现实世界中工作的系统。

UML超级结构的内容

在最高层次上，超级结构RFP要求：1)允许结构模式的建模， 例如基于元件的开发以及实时结构规范；2)澄清通用性、依赖性和关联性的语义；3)在行为建模中支持封装和拓展性(scalability)， 特别是在状态机和交互作用的情况下；4)去除在活动框图表建模中由于映射到状态机而产生的限制。

该RFP继而建议在UML1. x 中接口和结构的概念必须要加强， 以支持并简化对标准元件框架和结构的支持。另外它还规定必须加入数据流建模， 并澄清许多关系语义。更为重要的是， RFP提出顺序框图在表现力和语义方面的局限太多，建议应该加强这方面能力。另外， 活动框图在语义上应与状态机相区别。最后， 该RFP给出了去除UML1.x规范中的错误和不一致性。简单地说， 超级结构的请求是在结构和规模拓展性方面改进UML的能力和应用。

超级结构包含了UML2.0规范中“用户可视”部分。拓展性和架构是推动对RFP的需求的两个力量，它们之间有联系， 但又有明显不同的概念。特别是，定义一种能在“小系统”中很好应用，并能升级应用到“大系统”的建模概念(元类型)非常重要。我们不希望突然转换到一套完全不同的概念， 因为我们面对的是架构问题， 而不是别的小问题。这就需要在工作开始之前有预定的假设，该假设在实践中可能会有问题。

定义一套可扩展到架构应用的概念，远胜于一套将架构完全排除在外的概念。这两种概念是明显不同的：在UML2.0中，架构改变主要表现在结构(类)模型方面， 而拓展性变化在改进的顺序框图中表现最为明显。

结构类

元件和子系统显然是架构范畴内的概念，但它们是怎样与类联系起来？它们之间又是如何相互联系的？UML1.x在这些方面是模糊，UML2.0则引进了“结构类”的概念。结构类是一种由外在“嵌套”元件组成的类，目的是对容器分层结构(containment hierarchy)建模，这些分层结构是由“元件(part)”构成的类。

图1所示的简单的Rhapsody(I-Logix公司的UML工具)类解释了UML2.0中结构类的概念。“ElevatorCar” 由一序列的元件组成：按钮、目的楼层列表(和目的楼层本身)以及和一扇门。类似地， 一个楼层类具有一个请求电梯上下的按钮和一个指示电梯到达层面的指示器。它们都是结构类因为它们都能被分解成更基本的元件对象。Door、ElevatorGnome和shaft类也都是结构类， 不过它们在这个模型的其它部分进行分解.

图1

结构建模的另一个新增部分是端口，或者可实例化(instantiable)的连接点。端口可以与结构类一起使用，以允许“元件”(位于结构类之内) 输出特定服务，或者在外围结构类的边界上操作。端口的使用是一种设计模式，这样使用它也会带来正、反两方面的影响。但UML2.0将端口提升为第一位概念， 尽管对它的使用是可选的。

图2a是使用端口的示意框图。客户希望从属于某个服务机构的服务提供上得到某项服务，他使用电话(请求端口) 呼叫秘书， 秘书这是他在这个组织内唯一可见到的实体。他指出根据合同他可以请求某项服务，然后秘书作为中间人通过终端端口(终点在服务器处)传送这一请求到服务器。

图2

图2b是对应的UML模型。在类边缘的小盒子是(可选)端口。客户的“请求” 端口与接口的“请求”边相联系。而服务机构提供的“供应”端口与接口的“供应”边相联系、外部端口是一个中继端口，代表了通过其供应的终端口向服务器请求的服务。由此可见，端口仅仅是内部“元件”对象通过包封的结构类边界， 提供一系列特定服务的手段。图3更详细地展示了一个使用端口的例子――智能机械手臂。“实例的多重性”(在结构类中实例出现的次数)可用边角处的多样性表示，也可以用方括号来表示。 例如： 机械手臂中的7个直流马达就用DcMotor[7] 表示。 注意该框图既表示通用性――除非需要否则不用表示，又表示了关联性――诸如内部类的属性和操作等特性。这些仅仅是所有可能情况中的几种。

图3

UML2.0以2种方式扩展了接口的概念。首先，UML1.x 接口仅允许指定供应方， 这个功能被保留了。UML2.0还允许(可选的)指定请求(客户)方。接口也用另外的方式进行了增强。在UML1.x中，接口不包含属性和状态机，而UML2.0接口可以具有“虚”属性。 在UML2.0中的接口仍然不是可实例化的(instantiable)。

当标准规定了一套属性， 就要求类具备这些属性。另外，在UML1.x中， 接口的局限性之一是没有指定服务顺序的方法。我们都知道，许多系统要求某些服务有顺序，例如我会强烈要求我乘坐的飞机在落地前先放下起落架。

在UML2.0中，这些操作请求序列可以通过协议状态机来指定。协议状态机除了有一些限制之外，跟正常的状态机相同。它没有进入和退出的动作、活动、内部转换、历史状态等特性。它的目的是指定接口一系列的可能操作服务。 元件是一种结构类型，因此它可以选择具有端口和接口。

元件的记号与UML1.x中规定的有所不同。UML2.0规范规定在边角处有一个元件框图标或老套的“元件”字样。元件与子系统的关系在UML2.0中也得到了澄清。子系统通常比元件“大”， 并且可以包含元件。如果愿意，你可以在元件盒(component box，)的“artifacts”段指定元件或子系统，例如包含执行代码的文件。

状态框图的继承

对于“reactive”或“stateful”类(也就是具有状态框图的类)，人们自然希望该类的子类也能体现父辈的特征。UML1.x对此定义不清楚，但在UML2.0中， I-LOGIX采用的方法定义了“状态框图继承”。

事继承很有用的是“替代性”的概念。也就是说，一个子类的实例可以由超级类(superclass)来代替，而系统仍然有效并能正常工作。这里需要考虑对子类的继承状态框图的操作准则。我们可以通过添加“加入新状态”、“子状态”、 “与状态(and-states)”、“转换(transition)”和“动作(action)”进行扩展，并通过利用多形态方法重定位转换和修改动作列表。但不能删除转换和状态，或者重新指定状态的父辈(增加拥有这个状态的新的复合状态)。

UML2.0完全建立在UML1.x基础之上，大多数的UML1.x模型在UML2.0中都可用。但UML2.0在结构建模方面有一系列重大的改进，包括结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力的增强。当然还有时序框图，但如果你不使用这些功能，也就不用担心这些特性，因为仅使用类框图、顺序框图和状态框图仍可建立非常复杂的实时嵌入式系统。

顺序框图

对顺序框图进行修改主要是要达到两个目标：改进“规格性”(定义事务的能力)和“拓展性”。最明显的改变在后一个目标中得到体现。顺序框图可以被分解成“交换片段”， 而这些片段既可以表示在同一个或者另外的顺序框图中。

虽然UML2.x的顺序框图看起来与UML1.x的非常相像，例如它们都有生命线(lifeline)、消息等，但两者也有很明显的不同。其中一个不同是在框图右上角有一个5边形的盒子(见图4)，它是交互片断的“操作符”。在这个框图中，我们看到“sd例子”。操作符sd是该片断的名字。在这个大框图中， 还可以看到嵌套的另一个顺序框图，它的名字是“alt”， 是“alternative”的缩写(If/Then/Else)，它作用于被嵌套的片断。如果监视点(Guard)的值为“TRUE”， 则这个片断的上半部分被执行；相反地， 如果“else”监视点的值为“TRUE”，则执行下部分片断。这个标记比起UML1.x中的分支标记更加有效，同时还注意到了递归性。交互片断也可以包含一些嵌套的交互片断， 而它们都有适用于自已整个(嵌套的)片断的操作符。

图4

这些操作符包括：Sd――命名顺序框图；ref――引用“交互片断”；loop――重复交互片断；alt――选择；par――并发(平行)区域；seq――部分顺序(缺省值)；strict――严格排序；assert――必需的；opt――可选的“模板”；neg――“不可能发生”或有问题的规范。ref操作符允许引用在单独框图中定义的交互片段.

生命线也可以按照图5所示进行分解。这时实例线 “ServiceBase”可以分解成另一个框图(图5右下角中的小框图)。 消息的进入或退出点被称作“门(gate)”，它们能让工具确保顺序框图之间的兼容性和一致性.

图5

时序框图

顺序框图是观察服务要求顺序的一个有效方法， 但它还只是观察时间相关动作的一个次优方法。为了更详细表达时序，我开发时序框图，它们现在已经被UML2.0所采用并只做了很小修改。图6表示了一个简单的时序框图，竖轴表示状态，横轴表示时间。竖轴方向的值通常是离散的，比如状态和一些枚举类型的值。时序框图中离散值的数轴很常见，所有重要离散情况都可以使用，甚至是逻辑值或数学表达式。时序框图也包含顺序框图中的其它元素，例如门、消息和约束。

图6

图7显示了多个实例在时间上的协调关系，实例由虚线隔开。连续值有两种表现形式。缺省形式如图8的下半部分所示，值被保持直到它被改变。选取它作为缺省值是因为大多数离散系统都是严格据此工作的。对于值可在其中连续变化的物理过程和系统工程环境，可替代的形式可能更加适合。

图7

图8

其它资料

UML2.0的内容远比前面介绍的要多。可能最重要的一点是，UML1.x模型在大部分情况下都将继续有效。这里对内部元模型结构做了大量重新设计、再设计工作，并且随着对技术细节不断地推敲，这一工作还将继续。许多细小而重要的(对于某些人)的变化正在发生，如关联性(association)、关联子集、合并动作、活动等。虽然UML的基本性质和表现力没有变化，但仍有必要提及以下三件重大事项。

第一，交互框图将活动框图和顺序框图结合在一起，使活动框图成为了一系列顺序框图的“主框图”。这样人们就可以建立一个顺序框图的”地图”， 从而很容易地在其中浏览.

第二，在UML1.x中，活动框图和状态框图具有同样的语义。换句话说，它们表达同样的事情，但用了不同的标记。 在UML2.0中， 活动框图是基于Petri网络令牌语义， 而不是基于有限状态自动控制，因此更具有表现力。虽然它对计算算法不是很重要， 但是对过程建模很有帮助。

第三，UML2.0包含了表示结构元素(对象)之间数据流动的流程框图(Flow Diagrams)。它与协作框图(collaboration diagram)中的信息流动类似，但不完全相同。对于那些希望构建数据流框图式模型的建模者，可按照图9的UML方式进行建模。

图9

本文小结

UML2.0是完全建立在UML1.x基础之上，大多数的UML1.x模型在UML2.0中都可用。但UML2.0在结构建模方面有一系列重大的改进，包括结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力的增强。当然还有时序框图，但如果你不使用这些功能，也就不用担心这些特性，因为仅使用类框图、顺序框图和状态框图仍可建立非常复杂的实时嵌入式系统。

作者：Bruce Powel Douglass，email: bpd@ilogix.com

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号