UML 2.0的新改进可分为以下五个主要方面,按重要性顺序列出:
在语言定义方面精确程度有了相当的提高: 这就是支持自动化高标准需要的结果,此标准是MDD所必须的。自动化意味着模型(以及后来的模型语言)的不明确和不精密的消除,所以计算机程序能转换并熟练地操纵模型。
一个改良的语言组织: 其特性是由模块化决定的,模块化的特点在于它不仅使得语言更加容易的被新用户所采用,而且促进了工具之间的相互作用。
重点改进大规模的软件系统模型性能: 一些流行的应用软件表现出将现有的独立应用程序集成到更加复杂的系统中去。这是一种趋势,它将可能会继续导致更加复杂的系统。为了支持这种趋势,将更加灵活和新的分等级的性能添加到语言中去,用以支持软件模型在任意复杂的级别中使用。
对特定领域的改进的支持: 使用 UML 的实践经验证明了其所谓的“扩展”机制的价值。这些机制被统一化,精炼化后,使得基础语言更加简化,更加准确精炼。
全面的合并,合理化,清晰化各种不同的模型概念: 从而导致一种单一化,更加统一化语言的产生。它包含了合并和――在一些案例中――消除多余的概念,精练各种各样的定义,添加文字性的解释和例子。
现在我们来更详细地研究一下上述的每个方面。
精确程度
大多数的早期软件建模语言被非正式地定义,并很少注重它的精确性。时常,建模概念被解释成使用不严密的自然语言。由于大多数的建模语言在文件中或在Martin Fowler所提及的设计草图[Fowler04]中所使用,在那个时期,此模型概念得到了充分信任。这种思想传达了一种设计的本质特性,而把细节留给实现阶段去处理。
然而,由于模型在这种语言中很可能――并且通常是――被不同的商家解释成不同的含义,因此经常导致概念混淆。此外,除非模型解释的问题事先已被明确地讨论过,否则像这样的分歧还不能被人所发觉,而只是在发展的较后阶段才能被发现(即当问题的结果已明显显现时候)。
为了把不明确的概念减少到最少――并和多数现代的其它模型语言形成对比―― 第一个标准化的UML定义是用元模型来指定的。这是一个定义每一种UML 建模概念特性和这些特性与其他相关概念直接的关系的模型。使用UML的基本子集来定义这个元模型,并且通过一系列在对象约束语言中(OCL)正式的强制进行补充。
注释:: 这种UML子集,主要是由定义在UML上的类图上的概念所组成的,它被称为元对象工具(MOF)。选择这个子集后,它可以用来定义其它的建模语言。
这种结合所描述的是,UML抽象语法的一种正式的规范。正式的规范。之所以被称作是正式的,其原因是它与实际的符号或用于描绘模型的具体语法具体语法(也就是说,文本和图表)无关。换句话说就是,它所定义的规则集可以用来确定一个特定的模型是否已经很好的成形很好的成形。例如,这种规则将允许我们去测定通过一个状态机转换来连接两个UML类是不正确的。
然而,在这个初始的UML 元模型中所使用的精确程度证实,在MDD(例如在[Stevens02]中讨论所见到的)后,对整个潜能的支持是远远不够的。特别是,UML建模概念的语义(或含义)的规范,对这些作为自动代码生成或正式确认的基于MDD的活动仍旧是不适当的。
因此,值得注意的是在UML 2.0中定义所使用的精确程度已经增强了。它是通过以下方法完成的:
一种元模型架构的主要重建: UML 2.0架构是由一组低层次的建模概念和模式所组成的,它们在大多数的案例中要么过于初级,要么太抽象,以至于不能直接地在建模软件应用程序中使用。然而,它们相对的简单性使得它们在其语义和形成的规则上更加精确。这些优化后的概念,以不同的方法结合产生了更加复杂的用户级别的建模概念。例如,在UML 1中,在所有权角度上(即,元素包含另外一些元素),命名空间的概念(也叫唯一命名的元素集合)与分类器的概念(元素是能根据它们的属性进行分类的)上,都与单个的复杂语义概念绑定在一起。(注意这同样意味着如果没有包含另外两个而使用其中的任意一个的话,那是不可能的。)在新的UML 2.0架构中,这些概念被分离开,并且它们的语法和语义也被单独的定义。
可扩展的和更加精确的语义描述:UML 1模型概念语义的定义在许多方法都存在问题。它所描述的层次有些地方具有某些广泛的和详细的描述(例如,状态机),但是非常不平均,而其它的一些地方几乎没有解释。UML 2.0规范主要强调了语义,尤其是在基本行为动态的关键领域中(如下所述)。对于一个更加详细的UML 2.0语义的讨论,请参考资源部分中的[Selic04]。
一种清晰定义的动态语义框架: UML 2.0规范澄清了一些在老版本中的严重语义缺陷。图一描述了这个框架,至于更多的细节在资源中有所描述。[Selic04]。此外,下面的问题将通过这个框架详细的描述出来:
在运行期间的链接和实例的结构化语义
结构和行为之间的关联
语义的基础或因果关系模型通过所有当前在UML中的高级行为形式(即状态机,活动,交互)所共享。这同样也确保了那些通过不同的形式表达行为的对象可以相互的交互。
图 1. UML2.0语义框架
新的语言架构
UML 2.0 在精确度方面的提升所造成的最直接的结果之一,就是即使不算它所新增的建模能力部分,这种语言的定义也变得更大了。特别是对于最初的UML,曾被批评过于庞大(以至于学习和使用起来太麻烦),对于现在更加庞大的定义,这点通常又将被关注。
这样的批评典型地忽略了一个事实,那就是UML原本就是用来表述一些现在最复杂的软件问题,这样的问题当然需要功能充分强大的工具。(成功的科技——如同汽车和电子学,从来没有变得简单;对机器持续不断的要求是人类的本性之一,这就造成了最终越来越复杂的工具。例如,没有人会企图用基本的手工建造现代的摩天大厦。)
不过,由于有了这些顾虑,UML2.0 在某种程度上进行了模块化,允许有选择性的使用一些语言模块,以便解决语言复杂度的问题。这种结构的通常形式如图2所示。一些像类和关联这样的共享概念组成了它的基础部分,顶部是垂直的子语言或语言单元的一个集合,集合中的每个单元都很适合用来对某个具体的方面进行建模(Table 1)。这些垂直的语言单元一般都是相互独立的,因此你可以单独地使用它们。(注意:这在UML1中是不行的,在UML1中,活动的形式完全是基于状态机的形式。)
图 2. UML 2.0的语言架构
此外,垂直语言单元按级别组织成三层,通过在那些可用的层上增加建模能力可以形成相互连续的更高层。这就对模块性提供了更多的空间,即使对一个已给定的语言单元,你也有可能只使用某些特定的子集。
这样的架构意味着,你可以学习和使用UML那些最适合你的部分。你不再需要为了有效地使用UML去熟悉它所有的内容,就如同你不必为了说好英语而去学习英语里所有的内容一样,从这点来说,它可能比学英语更简单。随着你经验的增长,如果有必要你可以逐渐引入更强大的建模概念。
表1 UML 2.0的语言单元语言单元 目的 动作 (基础) 细粒度动作的建模 活动 数据和控制流行为建模 类 (基础) 基本结构的建模 组件 组件技术的复杂结构建模 部署 部署建模 通用行为 (基础)公共行为语义基础和时间建模 信息流 抽象数据流建模 交互 内部对象行为建模 建模 模型组织 Profiles 语言定制化 状态机 事件驱动行为建模 结构 复杂的结构建模 模板 模式建模 用例 非正式的行为需求建模
作为相同架构下重组的一部分,在UML2.0中,语言的定义和结构的灵活性被显著地简化了。在UML1中,规范性的基本单元是由元模型的包定义的,包含了差不多成百个可能的组合。(事实上,因为UML 1 为一个特定的适应性给出了规范化的但又不完全的灵活定义 ,也就是说这些性能可以有很多种不同的组合)这就意味着,几乎不可能找到两个或更多的建模工具能相互之间进行模型交换,因为每一种工具可能只支持包的一种不同的组合。
在UML 2.0中,只定义了三个规范性层次,那些对应于分级语言单元的层已经在0层中就被提及并描述了。它们是这样被定义的,层(n)的模型服从于任何比它更高的层(如n+1)所定义的模型。换句话说,一个符合给定层规范的工具可以从那些符合任一相同或低于它所在层规范的工具中导入模型――在没有丢失信息的情况下。
注释: 形式上,UML 2 也定义了第四层(层 0),但这只是一个内部层,主要用来供工具的实现者使用。
四种规范标准类型的定义
抽象句法规范标准
混合句法规范标准(也就是UML符号)
抽象句法和混合句法规范标准
抽象句法和混合句法规范,和图之间相互交换的标准
这就意味着最多有12种不同规范标准组合,并且它们之间有着清晰的从属关系。(比如,抽象和具体的语法标准与仅仅是具体的或仅仅是抽象的语法标准保持一致)。从而使得在UML2.0中不同厂商的工具之间的模型交换成为可能,而不仅仅只停留在理论上。