UML概要
UML概要
1.0 版
1997年1月13日
2800 San Tomas Expressway
Santa Clara, CA 95051-0951
版权所有 1997瑞理软件（Rational Software）公司。
本文档允许被影印、电子发行或被翻译为外语，如果完全复制本文档，请全文引用本提示，并包含下列声明：
通过环球网（WWW）地址 http://www.rational.com 可以得到统一建模语言（UML）的最近更新版本。
目录
该系列文档详细介绍了统一建模语言（Unified Modeling Language，简称 UML）。UML是一种用于描述、视化和构架软件系统以及商业建模的语言。它代表了在大型、复杂系统的建模领域得到认可的“优秀的软件工程方法”。
UML定义包括如下文档：
UML概要 － 简要介绍UML，并指导您对其它文档的阅读。
UML语义 － 介绍UML的规范元模型。UML元模型是UML语义的基础，是用UML表示法和简洁的自然语言表达的。UML词汇是该文档的附录。
UML表示法指南 － 介绍UML表示法，并提供了一些范例。
UML特定进程扩展 － 用扩展机制和特定进程的图符来描述UML特定进程的扩展。
这些文档可以从瑞理软件公司的网络站点http://www.rational.com获得。另外，OMG成员还可得到有关UML向OMG提议的其它文档（从ad/97-01-01到ad/97-01-14）。（参见网点http://www.omg.org 的OMG信息栏。）
该文档集主要对UML语义和UML表示法作了精确、一致的定义。 面向的读者主要包括OMG小组成员、其他标准化组织、作者、培训人员和工具开发人员。文档假定读者熟悉面向对象的分析和设计方法，所以其中概念相对密集，更强调语言的精确性而不是可理解性。虽然这些文档配合其他的资料可以作为对复杂系统建模的介绍，但这并不是我们的初衷。随着其他有关UML的书籍、培训课程和工具的普及，该系列文档将逐渐被更多的读者接受。
其他有关UML的信息以及UML的最新资料将登载在瑞理软件公司网络站点（http://www.rational..com/uml）上。
这一部分主要讨论在系统需求日益复杂的情况下，建模的重要性。
为什么需要建模语言
之所以为系统建模，是因为我们不可能全面的理解任何一个复杂的系统。随着系统复杂性的增加，先进的建模技术越来越重要。一个项目的成功有许多原因，严格的建模语言标准是其中一个重要的因素。建模语言应该包括以下几个部分：
模型元素 — 基本的建模概念和语义
表示法 — 模型元素的符号表示
准则 — 行业习惯用法
软件的前景随着软件的战略价值日益增长，企业期待着能够加速软件开发的技术，我们寻找着提高软件质量、降低软件成本和开发时间的方法。这些技术包括构件器，可视化编程、模式和框架。随着系统应用领域和规模的不断扩大，我们也探索管理系统复杂性的技术。特别是必须解决不断出现的体系结构难题，例如物理上的分布性、并发性、复制、安全、负荷平衡以及容错能力。
复杂性随应用领域和开发阶段的不同而不同。UML开发人员希望设计出能够恰当的表达不同领域、不同程度的体系复杂度的语义和表示法。
对实践精华的集成
开发UML的根本动机是集成先进的工业方法。包括基于不同的抽象层次、不同的应用领域、不同的体系结构、不同的开发阶段以及不同的实现技术的各领域的大量实践成果。统一这些先进的软件工程方法是开发UML的一个重要的目标。这个目标将在下一章详细讨论。
UML的前身
从70年代中期到80年代末期，随着方法学家在实践中对面向对象的分析和设计方法的探索，出现了最初的面向对象的建模语言。 独立的建模语言从1989年的不到10种猛增到1994年的50多种。即使是在这种“方法大战”的推动下，许多面向对象技术的使用者还是很难对某种建模语言表示完全满意。到了90年代中期，改进的方法陆续出现，最引人注目的有Booch ’93方法、不断完善的OMT 技术、和Fusion方法。这些方法不断吸收其他方法的优点，产生了一批卓越的软件开发技术，如OOSE、OMT-2和Booch ’93方法。这些软件工程方法都是完整的技术，但都只在某些方面具有优势。简单的说，OOSE方法是面向用例的方法，对商业工程设计和需求分析提供了良好的支持；OMT-2方法便于分析和开发数据密集的信息系统；而Booch-’93方法则更注重工程的设计和构造阶段，在开发工程密集的应用方面具有优势。
Booch、Rumbaugh和Jacobson联合行动
UML的开发始于94年8月，瑞理软件公司的Grady Booch和Jim Rumbaugh着手进行统一Booch方法和OMT（对象建模技术）的工作。由于Booch和OMT方法有很多相似之处，而且被公认为世界范围内面向对象方法的先驱，Booch和 Rumbaugh决定合作设计一门统一的建模语言。90年10月发行了统一方法（The Unified Method）的初版（0.8版）。同年秋天，Ivar Jacobson加盟联合开发小组，并力图把OOSE方法（面向对象的软件工程方法）也统一进来。
作为Booch、OMT和OOSE方法的创始人，Booch、Rumbaugh和Jacobson决定开发UML有三个原因：首先，这些方法有许多相似之处，通过这项工作，消除可能会给使用者造成混淆的不必要的差异是非常有意义的。其次，通过对语义和表示法的统一，可以稳定面向对象技术的市场，使工程开发可以采用一门成熟的建模语言，开发工具的设计者可以集中精力设计更优越的性能。第三，他们希望通过统一的工作，使所有的方法更进一步，积累已有的经验，解决以前没有解决好的问题。
当Booch，Rumbaugh和Jacobson着手进行统一工作时，他们制订了四个目标：
使用面向对象的概念构造系统（不仅仅指软件系统）的模型。
建立设计框架与代码框架间明确的联系。
解决复杂的、以任务为中心的系统内在的规模问题。
开发人与机器通用的建模语言。
开发应用于面向对象的分析和设计的表示法并不象设计一门编程语言那么简单。首先，设计者要考虑：表示法是不是应该能够表达系统的开发需求？是不是要把表示法设计成形象化的语言？其次，设计者需要在表达能力和简洁程度之间作一下折衷：过于简洁的表示法会限制应用的范围；而过于复杂的表示法又会吓倒刚入门的使用者。如果设计者是在统一已有的一些方法，则还要照顾到过去的基础：改变过多会使原来的使用者感到混乱。不作改进，又难以吸引更多的使用者。UML的定义力图在这几个方面平衡利弊。
经过Booch，Rumbaugh和Jacobson的不懈努力，UML 0.9和0.91版终于在1996 年的六月和十月分别出版。1996年间，UML开发者们虚心求教并收到了来自社会各界的反馈。他们据此作了相应的改进，但显然还有很多工作需要完成。
1996年，一些组织逐渐认识到UML对其业务的战略价值。我们与几个愿意为UML贡献力量的组织联合组成了UML合作者协会。那些对UML定义1.0版的开发作出很大贡献的组织有：Digital Equipment Corp.、HP、i-Logix、Intellicorp、IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、瑞理软件（Rational Software）公司、TI和Unisys。这些合作者联合开发了UML 1.0，一门严格定义、功能强大、应用广泛的建模语言。
UML 的合作者们提出了许多内行的建议，包括：OMG和RM-ODP技术、商业建模、状态机语义、类型、界面、构件、协同、求精、框架、分配和元元模型。以上所列仅是其中的一部分。UML 1.0是集体智慧的结晶。对UML开发作出贡献的人员名单在文档的谢启部分。
在本文档出版的同时，OMG小组正在考虑是否采纳UML作为对象建模方法的标准。
UML无专利权，是对外公开的。它致力于满足其基础方法的使用者和科学团体的需要。许多方法学家、组织和工具开发者已经在使用UML。UML在Booch、OMT和OOSE等先进方法的基础上建立起类似的语义和表示法，并且采纳了UML合作者和社会各界的建议，因此很容易得到广泛的认可。
UML对各种优秀方法的统一有两方面的含义：首先，它有效的消除了各种建模语言之间许多不必要的差异。更重要是，它统一了各种方法对不同类型的系统（商业系统或软件系统）、不同的开发阶段（需求分析、设计和实现）以及不同的内部概念的不同观点。
以下是UML的发展规划：
UML合作者协会将于1997年1月16日将UML文档资料提交给OMG。
UML合作者协会将在1997年上半年考虑OMG和公众的意见。
OMG将在1997年中期决定是否采纳UML作为对象建模方法的标准。
UML方法学家以及软件工业书籍的作者将在1997年出版有关的资料和书籍。
UML的标准化UML是在先进的面向对象方法的基础上建立起来的，因此许多组织都已经宣布支持UML为其组织的标准。UML已经做好了广泛应用的准备。UML 1.0版是稳定、实用的版本。这些文档可以作为作家撰写书籍和培训教材以及开发者设计形象化建模工具的第一手材料。其它的资料，如论文、培训课程、范例和书籍等，将很快推动UML的广泛传播。
根据对象管理小组（OMG）的分析和设计工作组的RFP-1，UML 1.0版的文档及其他资料，将在1997年1月提交。估计97年6月以前，OMG将决定是否接纳UML作为对象建模方法的标准。我们期待着UML及其定义继续得到发展。实际上，提交UML的准备工作已经并且将继续有力的推动UML的发展。
讨论小组及提供反馈
有一些电子研讨会适合对UML作一般性的讨论，包括Internet新闻组 comp.object。
UML合作者们可以通过电子邮件在网点[email protected]对UML发表意见。对UML文档特定章节的建设性意见，相对来说更容易被采纳。根据建议的数量，我们也许不会对每一邮件都作出回复。
工业化
许多组织和开发者都已经采用了UML。接受UML的组织将随着时间迅速增加。这将使UML定义更加实用，并鼓舞其他方法学家、工具开发者、培训中心和作家采用UML，从而继续促进统一建模语言的推广。
UML的巨大成功，将最终表现在其在工程上的成功应用和日益增长的对有关UML的支持工具、书籍、培训和指导的需求。
统一建模语言（UML）是用来对软件密集系统进行描述、构造、视化和文档编制的一种语言。
首先，也是最重要的一点，统一建模语言融合了Booch、OMT和OOSE方法中的概念，它是可以被上述及其他方法的使用者广泛采用的一门简单、一致、通用的建模语言。
其次，统一建模语言扩展了现有方法的应用范围。特别值得一提的是，UML的开发者们把并行分布式系统的建模作为UML的设计目标，也就是说，UML具有处理这类问题的能力。
第三，统一建模语言是标准的建模语言，而不是一个标准的开发流程。虽然UML的应用必然以系统的开发流程为背景，但根据我们的经验，不同的组织，不同的应用领域需要不同的开发过程。举个例子来说，开发错综复杂的软件是非常有趣的工作，但开发这种软件与构造严格实时的航空电子系统是大不一样的，后者是性命攸关的大事。因此我们首先把精力集中在设计通用的元模型上（统一不同方法的语义），其次是建立通用的表示法（提供对这些语义的形象化的表达）。虽然UML的开发者们将继续倡导从用例驱动到体系结构为中心最后反复改进、不断添加的软件开发过程，但实际上设计标准的开发流程并不是非常必要的。
UML的基本成分什么是呢？这个问题可以从两个方面来回答：UML
的定义及如何应用UML构造系统框架。
4.1.1UML定义的基本内容
为了有助于对统一建模语言本身（“内部”观点）的理解，我们把文档划分为UML简介（本文档）、UML语义、UML表示法指导和UML特定进程扩展这几部分。下面，我们将对这些文档的内容作简单的介绍。除了这些文档之外，其他有关UML的理解、范例以及习惯用法等内容的书籍也将陆续出版。
4.1.1.1 UML语义
该文档通过叙述性的语言和UML表示法对UML精确模型作了详细描述。UML开发者们用UML表示法及英文说明文字提出了一个严格的元模型。提出这个元模型是为了给UML要素的语法和语义作简单、一致的定义性说明。它把UML的语义与因人而异的最佳表达方法相分离，从而使开发者们能够对UML的语义达成一致意见。另外，这个元模型还使开发小组有可能通过（从某种意义上来说）统一UML的元素来大大简化UML。（例如，我们发现类型、模式和用例这三个概念之间存在着相似之处。）开发者们希望通过描述元模型的语义，从而选择那些能更精确的表达元模型的规范技术。
元模型是描述模型的语言。现在指对象模型。元模型非常重要，因为它能对模型的语法和语义提供简单、通用、明确的描述。在模型里，元的“层次”有点儿任意。UML的开发者们有意识的选择语义丰富的元“层次”，因为这是工具交互和复杂系统设计所依赖的语义丰富的协议的必然要求。
4.1.1.2 UML表示法指南
UML表示法指南集中介绍了UML的表示法，并给出了一些范例。当开发者或开发工具应用UML建造系统模型时，图形符号和文本语法是最直接可见的部分（“外部”观点）。这些图形符号和文字所表达的是应用级的模型。应用级模型是UML元模型的实例。UML标准的图表类型见 4.1.2 节。
4.1.1.3 UML进程扩展
该文档主要介绍UML扩展机制中的进程特定的扩展（例如，构造型, 特征值和限制条件等），以及其相应的符号（如果有的话）。
4.1.2开发过程
设计怎样的模型对问题的解决及系统的开发有重要的影响。抽象，即抓住相关细节、忽略无关信息，是学习和交流的基本方法。因为：
复杂的系统可以从系统模型的不同角度来更好的理解。只从一个角度来考察系统是不够的。
一个模型可以表示成不同的抽象层次。
优秀的模型是同实际相联系的。
UML从考察系统的不同角度出发，定义了下列图表：用例图
类图
行为图
状态图
活动图
时序图
协同图
实现图
构件图
安装维护图
这些图表从不同的侧面对进行分析或设计的系统进行描述。系统模型把这些不同的侧面综合成一致的整体，便于系统的分析和构造。尽管UML和其他开发工具还会设计出许多派生的视图，但上述这些图表和其他辅助性的文档是软件开发人员所见的最基本的结构。上述图表将在文档UML表示法指南中详细介绍。表示法和语义的发展史
UML是在Booch、OMT、OOSE等面向对象的方法及许多其他来源的基础上发展起来的。UML包含了来自许多人员的各种不同的观点，也受到了非面向对象方法的影响。UML表示法混合了不同的图形表示方法，剔除了其中容易引起混淆、冗余的、或者很少使用的符号，同时增添了一些新的符号。UML中的概念来自于面向对象技术领域中众多人员的思想。UML开发者们并没有提出其中大部分的观点，而只是对优秀的面向对象和计算机科学的方法加以选择和综合。表示法和语义的实际发展历程是非常复杂的，这里介绍的只是一些简单的背景知识，而不是详细的发展史。
UML用例图与OOSE方法类似。
UML的类图综合了OMT、Booch等面向对象方法中的类图。各种图表可以通过进程特定的扩展（如构造型及相应的符号）来支持其他的建模方法。
UML的状态图是对David Harel所提出的状态图的改进。UML活动图的基本语义与状态图大致相同，它类似于许多方法（包括面向对象技术以前的一些方法）中的工作流图。
你可以在许多面向对象的方法中发现UML时序图的影子（如交互作用、消息流 、事件流）等，甚至可以追溯到面向对象技术以前的方法。UML的协同图是通过对Booch方法的对象图、Fusion方法的对象交互作用图以及其他一些方法中的相关图表改造而来的。
协同是比较基本的建模元素，它构成了模式的基础。
UML的实现图（构件 和安装维护图）是在Booch方法中的模块和进程图（处理器关系图、处理器图）的基础上发展起来的，但UML的实现图以构件为中心而不是以模块为中心，相互之间的联系也更紧密。
构造型是UML扩展机制中的一种，它扩展了UML元模型的语义。构造型还可以附带用户定义的符号，以满足特定开发流程的需要。
上述的这些概念有着深远的渊源和影响，我们只能进行简单扼要的介绍。UML实际上是计算机科学和软件工程学长期发展的产物。
UML定义1.0版并没有提出开发工具和开发流程的标准，这是因为两者所考虑的问题有很大不同。标准化的建模语言是开发工具和流程的必要基础。
工具
对象管理小组的RFP（OADTF RFP-1）是推动UML开发的重要力量。RFP的初衷是增强开发工具彼此之间相互协作的能力，但实际上，开发工具及其可协作性在很大程度上依赖于一致的语义和表示法定义（如UML）。虽然UML定义的是语义元模型，而不是工具元模型，但这两者是非常接近的。在语义和表示法定义的基础上，很容易制订出一致的开发工具交互标准。
在向OMG提交UML的同时，UML开发者们还提交了一个依从UML的工具接口定义。这个定义在大批量数据传送的编码和语法方面采用了CDIF/ EIA标准。
UML文档中包括一些给工具开发者的有关具体实现的建议，但并没有对所有的问题作出回答。例如，文档中没有关于图表设计、色彩、用户索引、生动性等特点的内容。
开发流程
许多组织都把UML作为框架设计的通用语言，并在各种不同类型的开发流程中使用UML的图表。UML并不依赖于特定的开发流程方法，定义标准的开发流程并不是UML开发的计划，也不是OMG的要求。
但UML的开发者确实认识到了开发流程的重要作用。是否存在一个严格定义、管理方便的工作流程是区别项目水平高低的关键。繁重的编程并不是持久的商业开发方法。开发流程可以1）指导制订开发小组的行动规划，2）确定开发的框架，3）从总体上指导个人和开发小组的工作，4）提供监督和衡量项目成果及开发工作的标准。
项目的流程在本质上要满足不同组织、不同风格、不同应用领域的需要。在某些情况（例如错综繁绕的软件的开发）下有效的开发流程方法很可能在其他情况（如严格实时的系统开发）下效果并不是很好。应用领域、实现技术和开发小组的技能在很大程度上决定了工作流程的选择。
Booch、OMT、OOSE以及许多其他方法都有自己严格定义的开发流程，UML可以支持其中大部分的开发流程方法。虽然人们已经认识到了开发流程的重要作用，但流程标准化的问题还没有引起足够的重视。目前，更有可能发生的情况是人们普遍认同一些优秀的方法，选择某种开发流程的框架，并在这个框架的基础上规划自己的工作流程。虽然UML没有强制使用特定的开发流程，但UML的开发者们更提倡从用例驱动到以体系结构为中心最后反复改进、不断添加的软件开发过程，因此在UML定义中谨慎的提出了这个方法。
4.3UML与Booch、OMT、OOSE以及其他建模方法的比较
首先必须明确统一建模语言并没有从根本上脱离Booch、OMT或OOSE方法，而是对这些方法的有批判的继承。这就意味着，如果目前你是一名Booch、OMT 或OOSE方法的使用者，你接受的培训、你的工作经验和所偏好的开发工具都可以保留下来，因为统一建模语言是对这些方法的延续。对于其他方法的使用者来说，UML同样很容易接受。但这些方法的作者必须决定是否在他们的方法中采用UML的概念和表示法。
与Booch、OMT、OOSE等??他方法相比，统一建模语言有表达力更强、更清晰和一致的优点。因此，转而采用UML并不是毫无意义的，它可以使工程在更广的范围内建模。其他大多数方法和建模语言的使用者也会因采用UML而受益，因为UML消除了各种方法在表示法和术语上的不必要的差异，而正是这些差异隐藏了不同方法之间重要的相似之处。
相对于其他可视化建模语言，例如基于实体和关系的模型化方法、BPR流图、状态驱动的建模语言等，UML更富有表达力，机能更完善。
从现有的方法到UML，在表示法上会有略微的变化，但这并不需要使用者花很长的时间从头学习，而且可以使关键性的语义更加明确。如果UML统一的目标得以实现，那么随着有关UML的开发工具，书籍和培训课程的逐渐推广，UML将成为开发项目首选的建模方法。目前，许多可视化的建模工具将现有的表示法，如Booch、OMT、OOSE等方法，作为模型的不同视图；随着这些工具对UML的支持，使用者将会很容易的把其他方法的模型转换成UML模型，而不会丢失任何信息。
任何面向对象方法的使用者都可以通过短期的学习而获得与以前相同的表达能力。你可以很快就熟练掌握UML的基本使用。高级的UML技术，如构造型和属性的使用，还需要你更深入的学习。这些高级技术可以使模型更精确，更富有表达力。
UML的开发是为了简化建模方法，它抛弃了Booch、OMT和OOSE方法中的糟粕，而代之以其他方法中的精华。只有在没有现有的解决方法时，UML的开发者们才考虑增加新的特点。UML的开发者们是在设计一门语言（尽管只是一门图式语言），因此必须在简单（所有元素一律用方框和文字表达）和烦琐（为每个元素设计单独的符号）之间取得平衡。UML的设计者对增加新的元素非常谨慎，因为他们不想使UML过于复杂。尽管如此，UML中还是增添了一些新的元素，因为这些元素在其他建模语言的实践中已经被证明是非常有用的。
UML中增加了下列新概念：
构造型
责任
扩展机制：构造型、特征值及限制条件
线程和进程
分布及并发（如建模ActiveX/DCOM 和CORBA）
模式/协同
活动图（用于商业进程再工程）
类型、类和实例的明确区分
求精（处理不同抽象层次）
界面和构件
这些概念中的大部分都已经在其他方法和理论中提出了，UML把它们统一成一个整体。除了这些较大的变化外，我们还对Booch、OMT和OOSE方法的语义和表示法作了一些局部改动。在这里感谢那些为UML 1.0的开发和成功付出辛勤劳动的人们。
请通过e-mail地址[email protected]把您对UML的建议反馈给我们。
UML方法学家
Grady Booch, [email protected]
Ivar Jacobson, [email protected]
Jim Rumbaugh, [email protected]
UML 1.0开发小组成员
Digital Equipment
Paul Patrick, [email protected]
Jim Rye, [email protected]
Hewlett-Packard
Martin Griss, [email protected]
Reed Letsinger, [email protected]
i-Logix
Eran Gery, [email protected]
Prof. David Harel, [email protected]
ICON Computing
Desmond D’Souza, [email protected]
James Odell
James Odell, [email protected]
MCI Systemhouse
Cris Kobryn, [email protected]
Joaquin Miller, [email protected]
Microsoft
Philip A. Bernstein, [email protected]
Rick Hargrove, [email protected]
Andy Moss, [email protected]
Oracle
Guus Ramackers, [email protected]
Rational Software
Ed Eykholt, [email protected]
Grant Larsen, [email protected]
Dave Tropeano, [email protected]
Texas Instruments
John Cheesman, [email protected]
Bob Hodges, [email protected]
Glenn Hollowell, [email protected]
Keith Short, [email protected]
Unisys
Sridhar Iyengar, [email protected]
为UML的开发贡献力量及表示大力支持的人士我们对下列人士对UML的贡献、影响和支持表示感谢。部分人士虽然没有正式参与UML的开发，但还是要感谢他们对UML的影响。
Hernan Astudillo, Dave Bernstein, Michael Blaha, Gary Cernosek, Michael Jesse Chonoles, Magnus Christerson, Dai Clegg, Peter Coad, Derek Coleman, Steve Cook, Ward Cunningham, Raj Datta, Mike Devlin, Bruce Douglass, Staffan Ehnebom, Maria Ericsson, Johannes Ernst, Don firsmith, Martin Fowler, Eric Gamma, Dipayan Gangopadhyay, Richard Helm, Michael Hirsch, Yves Holvoet, Jon Hopkins, John Hsia, Ralph Johnson, GK Khalsa, Philippe Kruchten, Paul Kyzivat, Martin Lang, Mary Loomis, Robert Martin, Bertrand Meyer, Mike Meier, Randy Messer, Greg Meyers, Paul Moskowitz, Gunnar Overgaard, Jan Pachl, Bill Premerlani, Jeff Price, Jerri Pries, Terry Quatrani, Rich Reitman, Rudolf M. Riess, Kenny Rubin, Danny Sabbah, Ed Seidewitz, Gregson Siu, Jeff Sutherland, Dan Tasker, Andy Trice, Dan Uhlar, John Vlissides, Paul Ward, Rebecca Wirfs-Brock, Bryan Wood, Ed Yourdon, and Steve Zeigler.
