在学习UML的过程中，你可能会遇到结构建模的性能问题，这里就向大家介绍一下UML2.0如何规范改善结构建模的性能，主要包括UML超级结构的内容，结构类和状态框图的继承等内容，相信本节的介绍一定会让你收获不少。下面让我们一起看一下本节的具体介绍吧。
UML2.0规范改善了结构建模的性能
UML2.0完全建立在UML1.x基础之上，大多数的UML1.x模型在UML2.0中都可用。但UML2.0在结构建模方面有一系列重大的改进，包括结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力的增强。当然还有时序框图，但如果你不使用这些功能，也就不用担心这些特性，因为仅使用类框图、顺序框图和状态框图仍可建立非常复杂的实时嵌入式系统。
在UML(统一建模语言)2.0规范中存在4种有关的请求建议(RFP)文件：基础设施(Infrastructure)、对象约束语言(OCL)、元数据交换(XMI)和超级结构。基础设施RFP涉及UML的定义基础以及与OMG的元对象设施(MOF)的对齐。OCLRFP文件涉及对OCL的改善。实际上，除了那些定义UML的人员之外，很少有用户需要使用OCL。XMIRFP文件定义了一种交换语义模型信息的格式，但它目前没有指定如何交换框图表。XMIRFP文件则提出了改善定义交换框图表的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则引进了“结构类”的概念。结构类是一种由外在“嵌套”元件组成的类，目的是对容器分层结构(containmenthierarchy)建模，这些分层结构是由“元件(part)”构成的类。
图1所示的简单的Rhapsody(I-Logix公司的UML工具)类解释了UML2.0中结构类的概念。“ElevatorCar”由一序列的元件组成：按钮、目的楼层列表(和目的楼层本身)以及和一扇门。类似地，一个楼层类具有一个请求电梯上下的按钮和一个指示电梯到达层面的指示器。它们都是结构类因为它们都能被分解成更基本的元件对象。Door、ElevatorGnome和shaft类也都是结构类，不过它们在这个模型的其它部分进行分解.
结构建模的另一个新增部分是端口，或者可实例化(instantiable)的连接点。端口可以与结构类一起使用，以允许“元件”(位于结构类之内)输出特定服务，或者在外围结构类的边界上操作。端口的使用是一种设计模式，这样使用它也会带来正、反两方面的影响。但UML2.0将端口提升为第一位概念，尽管对它的使用是可选的。
UML2.0以2种方式扩展了接口的概念。首先，UML1.x接口仅允许指定供应方，这个功能被保留了。UML2.0还允许(可选的)指定请求(客户)方。接口也用另外的方式进行了增强。在UML1.x中，接口不包含属性和状态机，而UML2.0接口可以具有“虚”属性。在UML2.0中的接口仍然不是可实例化的(instantiable)。
当标准规定了一套属性，就要求类具备这些属性。另外，在UML1.x中，接口的局限性之一是没有指定服务顺序的方法。我们都知道，许多系统要求某些服务有顺序，例如我会强烈要求我乘坐的飞机在落地前先放下起落架。
在UML2.0中，这些操作请求序列可以通过协议状态机来指定。协议状态机除了有一些限制之外，跟正常的状态机相同。它没有进入和退出的动作、活动、内部转换、历史状态等特性。它的目的是指定接口一系列的可能操作服务。元件是一种结构类型，因此它可以选择具有端口和接口。
元件的记号与UML1.x中规定的有所不同。UML2.0规范规定在边角处有一个元件框图标或老套的“元件”字样。元件与子系统的关系在UML2.0中也得到了澄清。子系统通常比元件“大”，并且可以包含元件。如果愿意，你可以在元件盒(componentbox，)的“artifacts”段指定元件或子系统，例如包含执行代码的文件。
状态框图的继承
对于“reactive”或“stateful”类(也就是具有状态框图的类)，人们自然希望该类的子类也能体现父辈的特征。UML1.x对此定义不清楚，但在UML2.0中，I-LOGIX采用的方法定义了“状态框图继承”。
事继承很有用的是“替代性”的概念。也就是说，一个子类的实例可以由超级类(superclass)来代替，而系统仍然有效并能正常工作。这里需要考虑对子类的继承状态框图的操作准则。我们可以通过添加“加入新状态”、“子状态”、“与状态(and-states)”、“转换(transition)”和“动作(action)”进行扩展，并通过利用多形态方法重定位转换和修改动作列表。但不能删除转换和状态，或者重新指定状态的父辈(增加拥有这个状态的新的复合状态)。
UML2.0完全建立在UML1.x基础之上，大多数的UML1.x模型在UML2.0中都可用。但UML2.0在结构建模方面有一系列重大的改进，包括结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力的增强。当然还有时序框图，但如果你不使用这些功能，也就不用担心这些特性，因为仅使用类框图、顺序框图和状态框图仍可建立非常复杂的实时嵌入式系统。
【编辑推荐】
