UML 2001：标准化的《奥德赛》史诗 一个规范的标准化进程通常是一个冗长的过程。在UML 1.3的最终草案被批准之际，OMG UML修订任务组和OMG分析设计平台任务组联合主席Cris Kobryn于1999年10月在《COMMUNICATION OF THE ACM》上发表了本文，总结了UML的发展历程，并展望了其发展趋势。
在很短的时间内，UML已经成为软件工业中占支配地位的建模语言。目前它不仅是事实上的建模语言标准，也正在快速地成为法律上的标准。1997年，OMG采纳它作为标准建模语言。现在，OMG正在以ISO公共可用规范提交者的身份，申请将UML规范作为国际标准。
不过，一个规范的标准化进程通常是正式而漫长的，因为它要满足各种各样的技术规范和商业需求。从商业角度看，标准化的时间尺度通常与尽早使用最新技术的竞争需求是冲突的。从技术角度看，为了力求达成共识，则赞成这种"由委员会设计"的进程。
标准化之前的历史
早在1995年，Gray Booch和Janes Rumbaugh将他们的面向对象建模方法统一为Unified Method V0.8。一年之后Ivar Jacobson加入其中，共同将该方法统一为二义性较少的UML 0.9。同时，这三位杰出的方法学家被称为"三友(Three Amigos)"。
很快用户也认识到可对软件系统进行可视化、描述、构造和文档化的通用建模语言所带来的益处。他们充满激情地将这种语言的早期草案应用于不同的领域。受用户强烈需求的驱动，建模工具厂商也很快在它们的产品中加入了对UML的支持。
与此同时，UML成了实际上的工业标准。1996年，一个由建模专家组成的国际性队伍"UML伙伴组织"开始同"三友"一起工作，计划将UML提议作为OMG的标准建模语言。
1997年1月，伙伴组织向OMG提交了最初的提案UML 1.0。经过了九个月的紧张修订，于1997年9月提出了最终提案UML 1.1，这个提案在1997年11月被OMG正式采纳为对象建模标准。
有必要指出的是，由于比较仓促地通过了OMG的提交过程，尽管语言的基层结构和大部分上层结构是合理的，UML还是容忍了一些不尽如人意的负面因素：活动图的语义及表示法不完整；标准元素臃肿，其中有些元素是为了满足不同的、相互竞争的方法门派的需求而草率加入的，许多标准元素语义贫乏，而且命名和组织也不一致;结构混乱，所提交的规范并没有达到提交者预期的目标--用一种严格的元模型方法实现4层元模型结构，相反使用了一种实用但不精确的、松散的元模型方法，不利于UML同其他OMG规范的结合，比如与MOF（Meta Object Facility）的结合。
不过提交者们并没有因此推迟UML的标准化进程，而是在该语言的下一个修订版中解决了上述一些问题。
发展进程
OMG为修订标准而提供的基本机制是提案需求（RFP，Request for Proposals）和修订任务组（RTF，Revision Task Forces）。
其中RFP过程是OMG采纳新规范和改进已有规范的主要机制。任务组发布一个RFP，一个或多个提交团以规范草案作为初始提案响应该RFP，然后任务组对这些初始提案进行评估，并反馈给提交者，鼓励这些提交者与其竞争对手合作，从而形成最终提案。在任务组完成了对最终提案的评估后，就投票决定推荐众多提案中的哪一个。获得多数赞成票的提案就被送交组织委员会和主管该任务组的技术委员会去批准。
如果一个最终提案获得了所有的批准，它就成为被OMG采纳的技术。否则，任务组就有权重新发布一个修改过的RFP。
在一个规范被采纳后不久，将成立一个修订任务组，负责该规范的修订。1997年9月，OMG采纳UML 1.1规范之后不久，特许成立了第一个UML修订任务组，负责收集有关评论，并且提出修改建议。
该RTF提交的第一个主要产品是一个编辑版本UML 1.2，它改编了规范，使之与其他OMG规范更为一致。尽管这一版本纠正了印刷和语法错误，以及某些明显的逻辑上的不一致，但还是没有涉及对重要技术的改进。
该RTF的第二个主要的产品是其技术版本UML 1.3，它修正和改善了UML 1.1的遗留问题，并矫正了在此之后发现的许多小错误。该RTF一致推荐OMG批准其UML 1.3最终草案，并于1999年6月提交了一份最终报告。被推荐的规范随后被提交给组织委员会和平台技术委员会以获得批准。
演变的体系结构
UML是用元模型来描述的，元模型是4层元模型体系结构模式中的一层。此模式的其他层次分别是：元-元模型层、模型层和用户对象层。其中元模型层由元-元模型层导出，UML的元-元模型层在OMG MOF的元-元模型中定义，而UML元模型中的元类是MOF元-元类的实例。
元模型的体系结构模式已被证明可以用来定义复杂模型所要求的精确语义，这种复杂模型通常需要被可靠地保存、共享、操作以及在工具之间进行交换。它的特点如下：
● 它在每一层都递归地定义语义结构，从而使语义更精确、更正规。
● 它可用来定义重量级和轻量级扩展机制，如定义新的元类和构造型。
● 它在体系结构上将UML元模型与其他基于4层元模型体系结构的标准（比如MOF和用于模型交换的XMI Facility）统一起来。
在元模型层，UML元模型又被分解为三个逻辑子包：基础包、行为元素包和模型管理包。其中基础包由核心、扩展机制和数据类型三个子包构成，它是描述模型静态结构的语言底层结构，支持类图、对象图、构件图、部署图等结构图。行为元素包是描述模型动态行为的语言上层结构，支持不同的行为图，包括Use Case（用况）图、顺序图、协作图、状态图和活动图。模型管理包则定义了对模型元素进行分组和管理的语义，它描述了几种分组结构，包括包、模型和子系统。行为元素包和模型管理包都依赖于基础包。
UML 1.3的修订
UML 1.3是建模语言规范第一个成熟的发布。它纠正或调整了从UML 1.1中继承下来的遗留问题，并且修正了最终提交后的一年来所发现的大多数错误。从建模者的角度看，从UML 1.1到UML 1.3并没有很大变化，对语言的大部分改进是在底层对UML元模型语义的调整，只有很少量的变化是针对表示法的细枝末节的修改。底层结构上的变化对大多数用户来说是看不到的，但这使得UML在将来更容易实现和扩展。
● 解决UML 1.1的遗留问题
完善活动图的语义和表示法 增加了状态的动态激发语义，定义了执行条件线程的语义和表示法，而且增加了对象流功能。为了做这些修订，还需要对活动图所依赖的状态机语义做以下修改:为同步并发的活动加入"同步状态"、精化信号的语义、为合并状态转换定义附加的伪状态。
清理关系的标准元素 引入关系元类来组织各种类型的关系，并且把依赖构造型改造为依赖和流。此外，精练了泛化，不再需要以前的许多构造型（如继承、私有、子类、子类型等）。依赖和其他关系名称的一致性也有所改进。
体系结构的一致性 通过加入物理元模型和XMI(XML metadata Interchange)DTD定义，提高了UML 1.3元模型的体系结构跟MOF和XMI Facility的一致性。从UML语义逻辑元模型导出的物理元模型包含了一些支持产生IDL和XMI DTD的修改（例如将关联类转化为类）。尽管这样做与严格的元模型方法相左，但它为未来UML的修订达到这一目标提供了桥梁。
● 其他变化
静态结构图 放宽了限制，使类和接口之间可以关联，并且在类中可以声明信号。信号被定义为一个类元，可以操作。另外，还重新定义了模板和强类型的语义。
用况图 用况之间的关系被重新定义为三种主要类型：泛化、包含和延伸。
交互图 放宽了限制，使用户可以描述角色或实例。而且协作也可以泛化。
模型管理图 改进了模型和子系统的语义和表示法，将它们从包中分离出来，并使之更容易使用。澄清了对包的访问和引入权限的区别。
尽管UML规范的核心是语法和语义定义，但它还包括模型交换、语言扩展以及约束等方面的定义。UML 1.3对这些相关规范都进行了错误纠正，并使之与核心语言的改进保持一致。
为UML 2.0确立路标
该RTF在最终报告中明确了因为超出其范围或时间不允许而不能做的各种改进。他们建议下一个RTF应特别注意扩展性和文档管理方面的问题。对目前的扩展机制，用户和工具开发商已经发现了一些重要问题，而涌入新UML外围的提案可能会加剧这些困难。在文档管理方面，物理元模型和XMI DTD规范的加入大幅度地增加了UML规范的长度，并使它变得笨拙难用（它现在已有800多页了）。下一次UML修订将会把物理建模规范拆分为单独的文档。
该RTF还进一步建议负责起草UML 2.0 RFP的工作组考虑以下问题：
体系结构 使用严格的元模型方法定义一个与MOF元-元模型严格一致的物理元模型。给出改进的指导方针，以决定哪些部分应该定义在核心语言中，哪些部分应定义在UML的外围或标准模型库中。
扩展性 提供同4层元模型体系结构一致的扩展机制。提高外围规范的严密程度，使其支持用户对语言定制能力不断增加的要求。
构件 增强基于构件的软件开发的语义和表示法。
关系 提供"精化"和"追踪"依赖关系的基本语义。在多个抽象层次上定义关联的语义。
状态图和活动图 定义独立于状态图语义的活动图语义。在活动图和状态图中提供更随意的并发。详细说明状态机的泛化。
模型管理 重新定义模型和子系统的表示法和语义，以增强对企业体系结构视图的支持。
总体机制 定义一种模型版本管理的机制。详细说明图的互换机制。
体系结构的十字路口：是雕刻还是糊泥巴？
在UML 1.3最终报告中就体系结构问题强调指出：UML正在靠近OMG体系结构的十字路口。OMG希望通过对体系结构进行改进来完成技术上层结构规范（例如应用框架或商业构件），以补充用于进程间通信和分布式
操作系统服务的CORBA底层结构。虽然CORBA IDL对描述分布式计算底层结构特别有效，它可以用来刻画与界面关联的操作，但却不能用来定义方法、用况、协作、状态机、工作流以及通常与实际商业构件相关的各种关系。
因为UML允许用户定义IDL所缺乏的语义，所以可以用UML来补充IDL。（用UML完全代替CORBA IDL对大多数OMG成员而言变化太剧烈。）然而在这种情况下，对那些想用关系和行为升级IDL结构化规范的人而言，UML将面临如下的挑战：
学习的曲折性 UML是一种通用的建模语言，允许全面的语义表达。但尽管其基本的语言部分很容易掌握，更深层次的内容却需要足够多的时间去学习。
语义臃肿 作为一种通用的建模语言，UML的复杂性和庞大是不可避免的，但其中也包含了大量词义模糊、语义贫乏的标准元素。
轻量级的可扩展性 UML目前仅提供轻量级的扩展机制，如构造型、约束和标记。（相比之下元类是一种重量级的扩展机制。）这些机制将受到一些简单扩展的挑战，例如CORBA IDL接口的构造型，还将受到来自对扩展有更高需求的压力，诸如应用框架和分布式商业构件。
元模型癖好 由于元模型现在被认为是管理复杂的分布式体系结构的强有力技术，许多建模者都渴望用这种新式的重磅大锤来解决本来用砸核桃的锤子（例如构造型）甚至钉大头针的锤子（例如标准模型库中的一个类）就足以解决的问题。
这些挑战要求OMG采用一种雕刻的方法（少即是多）而不是糊泥巴的方法来提炼和扩展UML的体系结构。尤其是OMG需要采取有效的三层结构来决定哪些语言扩展可以处理为对UML核心的修订，哪些可以处理为独立的外围，而哪些可以处理为标准模型库。如果这个三层结构运行正常的话，核心部分将保持或提高其完整性，同时允许自然的选择（借助OMG过程）来遴选最可行的外围和标准化的模型库。
