UML应用

UML已经成为软件建模领域事实上的标准，它被成功地应用于许多领域，表达了众多不同的概念，例如：

• 程序语言实现（Java、C++、Smalltalk、CORBA IDL等等）的可视化表示；
• 直接可执行的模型（如xUML）；
• 与实现语言无关的软件规格说明
• 高层架构和框架描述
• 过程工程和重组
• 网站结构
• 工作流详述
• 业务建模

等等。

由于UML在各种不同的业务类型领域中以各种不同的方式得到了广泛运用，人们经常发现无法用现有的UML定义来表达他们所期待的东西，因此纷纷为UML添加了许多新的概念，使得它超出了规范的范围。

UML 2.0的提出

于是，OMG于1999年8月发布了一份反馈征集书（RfI），以了解用户认为必要的UML改进内容和增强方面。有多达21位个人、公司或社团回应了该RfI，他们列举出了广泛的主题，其中最主要的改进方面包括：

• 精确、无二义性的语言内核；
• 位于内核之上的其他概念
• 与元对象设施（MOF）的兼容性
• 一级类（first-class）扩展机制
• 对构件式开发的支持
• 类元（classifier）/接口/类/类型/角色的内部结构
• 根据语境限制关联
• 使对象约束语言的元模型与UML元模型更好的集成
• 状态机的一般化
• 状态机的伸缩性和封装
• 协作和序列图的伸缩性、封装和组织
• 架构建模
• 抽象数据流建模
• 从表示法到抽象语法的严格映射

此外，500多个正式的使用和实现问题被提交给了UML修订任务组（RTF）。其中很多问题已经在UML 1.4中获得解决，也有不少问题推迟到UML 2.0。

UML 2.0路线图

为了响应 RFI、500 多个正式问题和来自大量用户的非正式反馈意见，OMG于2000年9月颁布了UML 2.0的建议征集书（RFP）。该RFP分为3个独立的部分。

1）UML基础结构RFP

该RFP要求对UML的内核进行重构，简化它的基本设施，从而使UML变为一种模块化的可扩展语言。

UML基础结构的调整对大部分建模者没有直接影响，它的改变将影响工具开发商和创建UML扩展的方法学家们。其主要任务包括：

架构整合与重组

UML元模型过于庞大，缺乏良好的封装，难于维护、实现和扩展。因此需要：

• 通过定义一个内核语言来简化元模型；
• 通过增加抽象以及去除编程语言（如C++）特定的结构来清理UML元模型；
• 消除不一致性。

扩展性

UML现有的扩展机制有局限性，定义也太明确。UML 2.0将包含一个可在模型层（M1）使用的轻载机制和一个可在元模型层（M2）使用的重载机制。

2）UML上层结构RFP

UML的上层结构问题对UML建模者有直接的影响。UML 2.0将去除UML中含糊的部分，并根据用户的请求增加许多新的扩展。

结构建模

目前类型、类、接口与角色存在概念上的重叠，例如在协作图中的使用，这导致对前者的使用限制过多，而角色相比之下要灵活得多。

构件式开发

UML虽然包含了构件的概念，但过于简单。人们尝试用子系统和/或类来对软件构件建模，但结果不太令人满意。无法轻松地描述构件模型和架构框架（如EJB、CORBA构件模型和COM+等），例如：

• 无法详述构件的可插拔、可替换性。
• 接口的概念太弱。尤其缺少描述接口间交互的可能性和详述外出信号和消息的能力。
• 无法详述构件对其环境的要求。
• UML难于表达复杂的框架和模式。

运行时架构

UML活动图当前只在最低的粒度层次上支持对象/数据流。架构师应该能在更高的粒度层次上针对实体间的对象和数据流建模，比如包和子系统。

关系

几种类型的关系定义不明确。例如，包或状态机一般化（generalization）的含义没有被定义；“细化”和“追踪”依赖的定义也相当含糊。

活动图

活动图与其他图式的联系定义不明确，而且表达力过于受限。

交互

当前的交互图表示法既对利用序列图来组织规格说明帮助不大，也没有提供关于这些序列图如何相互关联的概览。问题包括：

序列图和协作图无法分解和组合。既需要对参与一次交互的角色的分解，也需要对序列本身的分解。

建模者无法从一个序列图引用另一个序列图。

表示法

UML的表示法存在一些不一致和缺点。表示法与元模型间的映射不正规，有些地方不明确、甚至有遗漏。

3）UML对象约束语言RFP

OCL既可用于定义针对UML元模型（以及OMG的其他元模型）的格式严整的规则，也可被UML用户用来表达UML模型中精确的约束。

OCL元模型

当前OCL的语义是建立在UML语义之上的，而两者的集成仅仅通过自然语言，OCL本身没有元模型，结果就导致OCL的语义和表示法之间没有明显的区分。这使精确地解释OCL出现了问题，例如UML模型中OCL表达式的语境没有完整的定义。没有一个OCL元模型，通过XMI来结构化地交换OCL约束是不可能的（尽管可将其视为未经解释的字符串），而且也很难保证OCL实现之间的一致性。因此OCL应该具有一个区别于其语法的元模型。

表达力和易用性

• OCL需要增加额外的概念，以便提供更加完整的构件规格说明以及对行为约束的详述。
• 需要定义OCL的扩展机制，从而可以一种明确的方式来扩展OCL并将其用于不同领域。
• 明确规定把OCL作为一种通用的UML表达式语言（仅是一种约束语言）来使用。 

结束语

2002年9月U2 Partners已经公布了UML 2.0规范最新的建议草案[2]，包含基础结构（UML: Infrastructure v. 2.0 R1 ）和上层结构（UML: Superstructure v. 2.0 beta R1 ）两个部分。

当前UML的演进方向正由用户群体引导，以确保它与软件工业的最新发展保持同步。UML 2.0将是漫漫长路上重要的下一步，只有不断地满足工业的需要，UML才能继续成为下一个十年的标准建模语言。