UML精粹译文（草稿）
[b]1.1、UML是什么？[/b][b]1.2、使用UML的方式[/b]
在软件开发中UML的本质角色在于人们通过不同的方式使用它，这也正是它与它迁移自其他图形建模语言的差异所在。这些差异导致了关于UML应该如何使用的漫长和艰苦的辩论。
为了排解这一状况，我与Steve Mellor 独立的提出了三种人们使用UML模式的描述：草图、蓝图及编程语言。到目前为止，至少在我眼中于UML最相似的是三者之中的草图。在这种方法中，开发者使用UML以帮助其理解系统的一些方面。作为蓝图，你可以以正向工程或反向工程的方式使用草图。正向工程在编码之前画UML图，而反向工程从已有的代码中构造UML图，以帮助程序员去理解代码。
草图的本质在于其可选择性。使用正向的草图，你可以粗略的描绘出你即将编写的代码中的一些问题，而这些问题通常由你所在团队的一组人进行讨论。使用草图的目的在于帮助大家交流观点以及对即将所作的事进行选择。你并不会讨论正在进行的所有编码工作，而仅仅是一些重要的方面，这些方面你想先通过你的同事认可或者你想在开始编程之前使设计的部分可视化。像这样的交谈可以很短：一次10分钟的谈话来讨论几个小时的编程或者是一天来讨论一个为期两周的迭代。
你可以使用草图以反向工程的方式解释系统一些部分是如何进行工作的。在你埋头于代码之前，你并不用展示每一个类，可简单的展示那些很有趣的以及值得讨论的类。
因为草图相当的不正式且动态性高，你需要快速、方便的使用它，所以一个普通的媒介白板则是必须的。在文档中草图也是非常有用的，在那样的情况下草图的使用不在于表达而在于文档的完整性。绘制草图的工具是一些轻质的绘画工具，通常人们并不严格按照UML的规则进行绘制。大多数在书中所展现的UML图，例如在我的一些其他的书里，都是草图。他们的选择强调的是在交流的上而不是完整的规范上。
与之相反，UML作为蓝图则强调的是完整。在正向工程中，人们认为蓝图是由那些为程序员编程构建详细设计的设计者开发的。设计应该足够完整使得所有的设计决策都能展现，并且程序员应该有能力去理解它就像去理解一个不需要思考的自然而然的活动。也许设计者同程序员是同一个人。但是通常来讲设计者是一个更高级别的开发者，他为一个团队的程序员进行设计。这一途径的灵感是在专家创建工程图的其他形式的工程中传递给建设伙伴以构建。
蓝图或许使用于所有的细节，或者说一个设计者也许会给一个特别的领域绘制蓝图。一个通常的做法是一个设计者开发深度至子系统接口的蓝图级别的模型，然后由开发者开发出继承上述模型的细节。
在反向工程中，蓝图的目的在于传递关于代码的详细信息，不管是存在于纸质文档中的还是作为一个交互的图形浏览器。蓝图以开发者易于理解的图形方式展示了关于一个类的所有细节。
蓝图需要比草图更复杂的工具，以处理任务要求的细节。虽然术语“用例”已经变成了滥用词，并且软件商尝试的去避免使用它，（Specialized Case tools）专业的用例（计算机辅助的软件工程）工具，进入了这一复杂工具集。正向工程工具支持图的绘制并且使用一个资料库进行备份以保留信息。反向工程工具读入源代码并将其解释到资料库中并且以此产生图。正向和反向工程都能执行的工具例如上述则称之为双向工具。
一些工具使用源代码的本身作为资料库而使用图作为代码中的图形视角。这些工具与编程联系紧密，而且常常直接集成于编译器。我倾向于认为这些是较直接的工具。
蓝图与草图之间的界限颇为模糊，但是我认为，其区别基于这样一个事实即草图是轻完整性而强调重要的信息，而蓝图则意图综合全面，通常带有减少编程至一个简单的相当器械活动的目的。简言的说，我认为草图更具有探测性而蓝图则具有确定性。
因为你使用UML越来越多并且编程已经越来越机械化，很明显编程应该实现自动化。确实，很多用例工具做一些形式的代码生成，正是这自动的构建了一个系统的重要部分。然而，最终你将达到所有的系统都能够被UML描述的点，以及你延伸了UML使其能作为编程语言。在这一环境下，开发者绘制能直接编译成可执行代码的UML图，那么 UML则成为了源代码。很明显，这一UML的使用方式要求特别复杂的工具。（正向及反向工程的概念对这一模式也没有任何意义，因为UML和源代码是同一种东西）。
Model Driven Architecture and Executable UML
（模型驱动架构及可执行的UML）
当人们讨论UML的时候，他们也常常讨论模型驱动架构MDA。从本质上讲，MDA是将UML作为一种编程语言使用的一个标准方式。这一标准由OMG控制，也是基于UML的。通过建造一个建模环境使其遵从于MDA，生产厂商能创建模型使其能够与其他MDA集成环境工作。
MDA通常被作为与UML相提并论，因为MDA使用UML作为其基础建模语言。当然，你不必为使用MDA而去使用UML。
MDA将开发工作一分为二。建模者通过创建一个与平台独立的模型（PIM）描绘一个特别的应用。PIM是一个UML模型，它独立于任何特定的技术。工具能够将PIM转化为指定平台的模型（PSM）。PSM是一个系统的模型旨在适应于特定的执行环境。然后工具能进一步为特定的平台处理PSM及生产相适应的代码。PSM能够作为UML但是并不必要。
因此如果你想使用MDA建造一个数据仓库系统，你可以开始于创建一个数据仓库系统的PIM。然后如果你想让这一数据仓库系统运行在J2EE和.NET上。你将会需要使用一些厂商的工具来创建两个PSMs：每个平台需要一个PSM。然后更深入的一些工具将为这两个平台产生代码。
如果PIM到PSM到最终的代码这个过程完全自动化的话，我们将能够使用UML像编程语言一样。如果这些步骤中的任何一部要人工来完成，我们只是能够使用uml蓝图。Steve Mellor 长期活跃在这一类型的工作中并且近来使用了“可执行的UML”的术语。可执行的UML类似于MDA但是使用的是不同的术语。类似的，你可以开始于一个平台独立的模型，这一点等同于MDA的PIM。然而，下一步是在单独的一步中使用模型编译器将此UML模型转化为可部署的系统；因此并不需要PSM。正如未来编译器所建议的，这一步骤完全自动化。
模型编译工具都是基于可重用的原型。一个原型描述如何获取可执行的UML模型以及将其转化为特定的编程平台。因此对于数据仓库的例子，你将要购买一个模型编译器及两个原型（J2EE和.NET）。在你的可执行UML模型上运行每一个原型，你将拥有数据仓库系统的两个版本。
可执行的UML并没有使用UML的所有标准。很多UML的构造被认为是没有必要的而因此没有使用。结果可执行的UML比FULL UML要简单。
这些听起来都非常好。但是实际上是怎样？我认为在这里存在两个问题。第一个是工具的问题：是否足够成熟能够做这一工作。这是随时间而改变的。当然正如我所写的，他们并没有广泛的使用，实际上我并没有看见过很多这种工具。
一个更基本的问题是UML作为一种编程语言的全部概念。在我看来，使用UML作为一种编程语言是值得的只有在于其比其他编程语言能产生显著的多产。基于过去我所工作过的大量的图形开发环境而言，对此我并不确信。即使它是更多产的，它仍然需要获得决定性的多数使用者以使其成为主流。这是它自身的一个巨大障碍。像许多老的Samlltalk的使用者一样，我认为smalltalk 比当前主流语言更多产。但是现在这仅仅是一个没落的语言，我并没有看到很多的项目使用它。为了避免Smalltalk的命运，UML必须更幸运即使它很优秀。
一个围绕着UML作为编程语言的有意思的问题是：如何建模行为逻辑。UML2 提供了三种行为建模的方式：交互图，状态图及活动图。这三种都有使用他们编程的支持者。如果UML作为编程语言获得流行，那么看这些技术中哪一种取得成功将会很有意思。
人们看待UML的另一种方式是在概念上使用它以及在软件建模中使用间。大多数人对于UML使用于软件建模中很熟悉。在这一软件的视角中，UML 的元素相当直接的映射到软件系统的元素。正如我们即将看到的，映射并不是规定性的，但是我们使用uml的时候，我们实际上谈论的是软件的元素。
以概念的视角，UML则描绘了一个领域研究概念的描述。在这里，我们并不谈论软件的元素甚至连我们建造一个词汇来讨论一个特定域也不。
并不存在关于视图的硬性规则；事实证明，存在真正的大范围的使用。一些工具自动的将源代码转换为UML 图，将UML 看作是源代码的一个可选的视角。这真的是一个软件视角。如果你使用UML图尝试去理解具有大量含义的并带有一群会计师的术语资产池，你更多的只是了解UML概念的框架。
在这本书的之前版本，我将软件视角分割为规格说明书（接口）和实现。实际上，我发现很难给它们两个划清界限，因此我觉得它们的区别不值得再大惊小怪。然而我总是在我的图中倾向于强调接口而不是实现。
这些使用UML的不同方式导致了一系列的关于UML图的含义及它们与UML图之外的世界的关系的争论。特别是这影响了UML与源代码之间的关系。一些人认为UML 应该被使用来创建一个设计，这一设计独立于用于实现此设计的编程语言。其他人认为独立于语言的设计是矛盾的，只是着力于强调白痴。
另一个不同的观点是什么是UML的本质。在我看来，大多数的UML使用者，特别是草图的使用者，看待UML的本质将会是图。然而，UML的创建者认为图表是次要的，UML的本质是元模型。图仅仅是元模型的一种描述。这一观点对蓝图使用者及UML编程语言使用者同样有意义。
因此无论何时你读到任何设计到UML的东西，理解作者的观点的内涵是很重要的。只有到那时你才能理解那些对UML所支持的观点的激烈辩论。
说了这么多，我需要明确我的观点。大多数时间，我使用UML是作为草图。我发现UML草图对于正向及反向工程并且无论是在概念还是软件视角上都很有用。
我并不是一个详细的正向工程蓝图迷。我相信很难做好并且将会使开发的速度降低。子系统接口级别的蓝图是合理的，但即使是这样你应该对那些开发者通过接口实现交互的接口的改变做准备。反向工程蓝图的价值依赖于工具是如何工作的。如果将其作为动态浏览器使用，那将会很有帮助，如果仅仅是产生一堆文档，那么它所做的只是无用功。
我认为UML作为编程语言是个不错的注意，但是怀疑它将来是否能够得到重要的应用。对于大多数编程任务来说图形形式是否比文本形式更多产我并不能够确信，但即使是这样，这很难使一门语言得到广泛的接受。
由于我的偏见，这本书关注的主要是使用UML作为草图。幸运的是，这是一本有用的简要指南。而且我不能够以这本书这样的篇幅公正的讨论UML的其他形式。但是这样篇幅的一本书能够成为其他书籍的敲门砖。所以如果你对UML其他形式没有兴趣的话，我建议你把这本书看作一个引导，在你需要其他书的时候你也可以去看其他的书。如果你只是对草图有兴趣，这本书也许会满足你的所有需求。
1.3、UML的发展历史
我必须承认我是一个历史爱好者。对于轻松阅读我最好的想法是一本历史书，但同时我也知道这并不是每一个人寻找乐趣的想法。在这里我谈论历史是因为在许多方面，我认为没有理解UML如何到来的历史我们就很难理解UML在何处。
在20世纪80年代，“对象”开始从实验室中走出来并向“现实”世界迈出了第一步，Smalltalk被稳定到一个平台是人们得以使用，C++也诞生了。在那个时候，各种各样的人开始思考面向对象图形设计语言。
最关键的关于面向对象图形建模语言的书出现在1988年到1992年之间。领军人物包括Grady Booch[Booch,OOAD];Peter Coad[Coad ,OOA],[Coad,OOD];Ivar Jacobson (Objectory) [Jacobson，OOSE]; Jim Odell[Odell];Jim Rumbaugh(OMT)[
Rumbaugh,insights],[Rumbaugh，OMT];Sally Shlaer 及Steve Mellor[Shlaer and Mellor, data],[Shlaer and Mellor,states];以及Rebecca Wirfs-Brock（Responsibility Driven Design）[Wirfs-Brock].
这些作者中的每一个现在都非正式的领导一些喜欢他们观点的从业者。所有的这些方法都非常的相似，但是他们之间常常包含着一定数量的不同。相同的基本观点会出现非常不同的记号，而这导致了客户的困惑。
在这使人困惑的时刻，正如说的那样标准化被忽略了。隶属于OMG的一个团队尝试着标准化但得到的仅仅是所有关键的方法学家的一封公开的抗议信。（这是我想起了一个古老的笑话。问题：方法学家与恐怖分子之间有什么不同？答案：你可以同恐怖分子进行谈判。）
最初导致UML形成的激变事件是Jim Rumbaugh离开GE公司加入了Grady Booch所在的Rational公司（现在是IBM的一部分）。Booch与Rumbaugh的联盟最初被看作是能够获得市场份额的临界事件。Grady和Jim宣称“方法战时代已经结束-我们赢了”。基本上是宣告他们将要达到标准化。“微软的方式。” 一些其他的方法论学者建议形成一个反Booch联盟。
到OOPSLA’95的时候，Grady与Jim已经准备好了方法合并之后的第一次公开描述:统一方法的文档版本为0.8。还有更重要的，他们宣称Rational软件已经购买了Objectory，从那以后Ivar Jacobson将会加入统一团队（Unified team）。Rational主持了一个有众多人参加的关于发布0.8版本草稿的宴会的庆典。（这一宴会的亮点是第一次公开展示了Jim Rumbaugh的歌喉；我们希望这也是最后一次）。
下一年出现了一个更开放的进程。OMG这个曾经大多数时间在旁观的组织，此时正承担着一个活跃的角色。Rational不得不整合Ivar的观点同时得花时间整合其他伙伴的。更重要的是OMG决定担当主要的角色。
在这一点上，明白OMG为什么参与进来是很重要的。方法论者，例如书的作者们，喜欢认为他们是重要的。但我认为OMG并没有听到那些作者的尖叫声。真正是OMG参与进来的是工具生产厂商的尖叫声，这些厂商都非常担心标准被Rational公司所控制，这将会给Rational工具取得一个不公平的竞争优势。因此厂商激发OMG在（用例）Case工具的互操作性标语之下去做一些事情去阻止。这一标语是重要的因为OMG谈论的都是互操作性。创建UML的观点将会使得Case工具能够自由的互换模型。
Mary Loomis及Jim Odell主持了初步的工作。Odell明确了他不准备使他的方法称为标准，但是他并不想要一个被Rational所影响的标准。在1997年一月，各种各样的组织提交了关于方法标准的建议以利于模型的互换。Rational协助其他组织机构并如他们所建议的发布了UML文档的1.0版本，第一次回答了此物的名称统一建模语言。
然后在各种不同力量交织的短期内，大量不同的建议终于合并。OMG采纳了最终版本1.1作为OMG的官方标准。一些修订仍在继续。修订版1.2完全是表面的。修订版1.3的修订更重要。修订版1.4加入了一些详细的围绕着组件及配置（Profiles）的概念。修订版1.5增加了动作语义。
当人们讨论UML的时候，他们大多认为Grady Booch，Ivar Jacobson，及Jim Rumbaugh是创始者。他们通常被称为三友，虽然说话是要下降第二个单词的第一个音节。虽然他们相信UML，但是我认为某些时候给三友绝对的信任是不合理的。UML的标记符第一次形成是在Booch及Rumbaugh的统一方法中。从这之后，大部分的工作都由OMG委员会领导。在这最后的阶段，Jim Rumbaugh是这三个中唯一一个做了重要的贡献的。我的观点是UML委员会的这些致力于UML的成员值得得到主要的荣誉。
1.4、标记符及元模型
当前状态的UML定义了标记符以及元模型。标记符是存在于模型中的图形的内容，它是建模语言的图形语法。例如：类图标记符定义项及概念如类、协作、多重性等是如何表示的。
当然，这引起了对于协作及多重性甚至一个类的精确含义的质疑。常见的惯用法提出了一些非正式的定义，但是许多人希望比之更严密的定义。
在正式方法的领域中有严格的规范说明和设计语言的观点最流行。在这样的观点中，设计、规格说明都是表示使用如术语微积分的导数。这样严格的数学定
义且不允许含糊。然而这些定义根本不通用。即使你能够证明一个程序满足数学规定，但并没有任何方法去证明这一数学规定满足系统的真实需求。
大多数图形建模语言并不严密。他们的标记符倾向于直觉的东西而非正式的定义。大体而言，这看起来并没有什么害处。这些方法也许是非正式的，但是许多人仍然发现他们很有用——有用才是重要的。
而方法论者都在寻找一种方法：在不牺牲他们的实用性的前提下去改进方法的严密性。一种路线是定义一个元模型：一个图，通常是使用一个类图类图定义这种语言的概念。
Figure1.1这是一个UML元模型的小片段，展现了各种特征之间的关系（精华是让你尝尝UML元模型的味道。甚至我不想尝试解释它）。
Figure1.1 A small piece of the UML meta-model
（uml元模型的微小片段）
元模型能够在多大程度上影响一个建模标记符的使用者？这个问题的答案总体上要依据惯用法的使用方式。草图者使用时并不怎么注意使用方式；蓝图者应该比草图者更在意。对于那些把UML作为一门编程语言的使用者来说使用方式是最重要的，因为它定义了这种语言的抽象语法。
大多数参入UM持续发展的人，主要是都对元模型有兴趣，特别是它对UML及编程语言的使用方式是非常重要的。标记符的问题通常放在次要的位置，如果你想要熟悉标准文档本身的话，请谨记这一点。
如果你更深入了UML的更详细的用法，你会意识到你需要比图形标记符更多的东西，这就是UML工具如此复杂的原因所在。
在这本书中我并不打算使用严格的方式。我将使用传统的方式，主要让你通过直觉来了解它。这对于一个主要倾向于使用草图惯用法的作用来说，使用这种方式写一本小篇幅的书是很自然的。如果你喜欢更严格的方式，你应该去参阅更详细的宝典。
1.5、UML图
UML 2中描述了被列在表1.1中的13种正式图，我们可以按照图1.2的方式将它们分门别类。虽然这些图是许多人学习UML以及我组织本书的方式，但是UML的创始者并不认为这些图是UML的核心部分。因此，这些图的使用并不严格。通常你可以在一种图上使用另一种图的元素。UML的标准指出某些特定元素的典型用法使用在一定的图中，但这并不是强制性的。
图1.2 UML图的种类
Table 1.1.UML正式图的种类
Diagram Chapters Purpose 引进版本
活动图 11 过程及并行行为 UML 1
类图 3，5 类、特征及关联 UML 1
通信图 12 对象间交互；重点在于对象间链接 UML 1协作图
组件图 14 组件间的组织结构及连接 UML 1
组合结构图 13 运行时类实例形态 UML 2
部署图 8 将制品部署到节点 UML 1
交互概况图 16 序列图与活动图的混合 UML 2
对象图 6 实例形态的举例 UML1非官方
包图 7 编译时的分层结构 UML1非官方
序列图 4 对象间的交互；强调序列 UML 1
状态机图 10 事件在对象的周期内如何改变状态 UML 1
时序图 17 对象间的交互；强调时序 UML 2
用例图 9 描述用户与系统如何交互 UML 1
1.6、什么是合法的UML
咋一看，会认为这应该是一个很容易回答的问题：合法的UML应该是在规格中有良好定义的东西。然而，事实上，答案略微有些复杂。
这个问题一个比较重要的部分是要清楚UML是否有描述性或法定的规则。一门语言的法定规则由官方团体所控制，这个团体规定在语言中什么是合理的，什么是不合理的以及你使用该种语言的表达的意义为何。具有描述性规则的语言就是你可以通过观看其他人实际怎么使用他们来理解它的规则。编程语言倾向于拥有法定规则，这一规则通常由标准委员会及主导厂商设定，而自然语言比如英语倾向于拥有描述性的规则，它的意义往往是约定俗成的。
UML是一门非常精确的语言，因此你可能会期待UML有自己的法定规则。但UML通常被认为软件中同与其他工程学科的蓝图相当，这些蓝图并不是法定的标记符。没有委员会规定在结构工程绘图中什么才是合法的样式。与自然语言类似，标记符往往也是俗成的。仅仅一个标准，很难达到理想的效果。因为在这个领域的所有人不可能会遵照标准的所有方面。正好去问法国人关于法国科学院。另外UML如此复杂，所以标准通常以多种方式解释。甚至那些审阅了这本书的UML创始者也对UML标准的的解释持有不同观点。
这个问题对于我写这本书以及你使用UML是都很重要。如果你想理解UML图，认识到理解UML标准并不能了解所有的事情是非常重要的。人们采纳约定，不仅在工业上很普遍，在一个特别的项目里也一样。因此，虽然UML的标准是了解UML信息的最主要的来源，但是这并不是唯一的来源。
我认为，对于大多数人来说，UML具有的是描述性的规则。UML标准对于UML意味着什么的影响是首屈一指的，但是它并不是唯一的影响。我想这一点在UML2中变得特别正确，UML2中引入了一些俗成的标记符，这些标记符不仅与UML1的定义而且与UML的一些惯用法有冲突，同时对UML增加了一些复杂性。因此，在这本书中我尝试着按我所研究的去总结UML。我将使用术语“约定用法”去展示一些在UML中广泛使用的但是UML标准中不存在的东西。
其中如果符合UML标准，我将使用“标准”或“规范化”的术语（人们使用“规范化”术语来表明你必须遵行UML标准以使自己合法。因此非规范化的UML是以一个非常美好的方式来表明它并没有严格遵循UML标准。）
当你在看一种UML图的时候，应该牢记一个准则：任何信息在UML中都有可能被UML图所隐藏。
这种隐藏通常会发生在——隐藏所有的属性——或者明确的——不展示这三个类。因此在图中你不能因为它的缺失而推断其它任何事情。如果多重性的值缺失，你不应该去推断它可能的值。即使UML元模型都有默认值，例如属性通常默认值为1，如果你在图上不能够找到相应的信息，也许可能是因为它是默认值或是被隐藏了。
话虽如此，这里通常有一些约定俗成的内容，比如设置多值属性。在文中，我将指出默认的规则。
如果你习惯于素描或蓝图，没有必要过分强调UML的合法性，而更重要的是使你的系统有一个良好的设计。我倾向于虽不正规的UML但有一个良好的设计的系统而不是虽然UML使用的很规范，但是是非常差的设计。很明显良好而又规范的设计是最好的，但你应该专注于拥有一个良好的设计而不是去考虑UML的奥秘。（当然，你应该合法的使用UML作为一种编程语言，否则你的程序不会顺畅的运行。）
1.7、UML的含义
与UML有关的一个比较尴尬的问题是：虽然规格说明书中详细描述了良好的UML的形态，但是对于在UML元模型外部的纯纯世界UML到底意味着什么，却没有什么可说的。没有UML怎样映射到一种特定编程语言的正式定义存在。光看着UML图，我们不能精确的了解与之等同的代码到底是什么样的。然而，你可以粗略的感受到代码将会怎样。实际上，这已经足够有用了。开发团队常常基于此形成他们的固有惯例，你将需要熟悉它们所用的惯例。
[b]1.1、UML是什么？[/b][b]1.2、使用UML的方式[/b]
在软件开发中UML的本质角色在于人们通过不同的方式使用它，这也正是它与它迁移自其他图形建模语言的差异所在。这些差异导致了关于UML应该如何使用的漫长和艰苦的辩论。
为了排解这一状况，我与Steve Mellor 独立的提出了三种人们使用UML模式的描述：草图、蓝图及编程语言。到目前为止，至少在我眼中于UML最相似的是三者之中的草图。在这种方法中，开发者使用UML以帮助其理解系统的一些方面。作为蓝图，你可以以正向工程或反向工程的方式使用草图。正向工程在编码之前画UML图，而反向工程从已有的代码中构造UML图，以帮助程序员去理解代码。
草图的本质在于其可选择性。使用正向的草图，你可以粗略的描绘出你即将编写的代码中的一些问题，而这些问题通常由你所在团队的一组人进行讨论。使用草图的目的在于帮助大家交流观点以及对即将所作的事进行选择。你并不会讨论正在进行的所有编码工作，而仅仅是一些重要的方面，这些方面你想先通过你的同事认可或者你想在开始编程之前使设计的部分可视化。像这样的交谈可以很短：一次10分钟的谈话来讨论几个小时的编程或者是一天来讨论一个为期两周的迭代。
你可以使用草图以反向工程的方式解释系统一些部分是如何进行工作的。在你埋头于代码之前，你并不用展示每一个类，可简单的展示那些很有趣的以及值得讨论的类。
因为草图相当的不正式且动态性高，你需要快速、方便的使用它，所以一个普通的媒介白板则是必须的。在文档中草图也是非常有用的，在那样的情况下草图的使用不在于表达而在于文档的完整性。绘制草图的工具是一些轻质的绘画工具，通常人们并不严格按照UML的规则进行绘制。大多数在书中所展现的UML图，例如在我的一些其他的书里，都是草图。他们的选择强调的是在交流的上而不是完整的规范上。
与之相反，UML作为蓝图则强调的是完整。在正向工程中，人们认为蓝图是由那些为程序员编程构建详细设计的设计者开发的。设计应该足够完整使得所有的设计决策都能展现，并且程序员应该有能力去理解它就像去理解一个不需要思考的自然而然的活动。也许设计者同程序员是同一个人。但是通常来讲设计者是一个更高级别的开发者，他为一个团队的程序员进行设计。这一途径的灵感是在专家创建工程图的其他形式的工程中传递给建设伙伴以构建。
蓝图或许使用于所有的细节，或者说一个设计者也许会给一个特别的领域绘制蓝图。一个通常的做法是一个设计者开发深度至子系统接口的蓝图级别的模型，然后由开发者开发出继承上述模型的细节。
在反向工程中，蓝图的目的在于传递关于代码的详细信息，不管是存在于纸质文档中的还是作为一个交互的图形浏览器。蓝图以开发者易于理解的图形方式展示了关于一个类的所有细节。
蓝图需要比草图更复杂的工具，以处理任务要求的细节。虽然术语“用例”已经变成了滥用词，并且软件商尝试的去避免使用它，（Specialized Case tools）专业的用例（计算机辅助的软件工程）工具，进入了这一复杂工具集。正向工程工具支持图的绘制并且使用一个资料库进行备份以保留信息。反向工程工具读入源代码并将其解释到资料库中并且以此产生图。正向和反向工程都能执行的工具例如上述则称之为双向工具。
一些工具使用源代码的本身作为资料库而使用图作为代码中的图形视角。这些工具与编程联系紧密，而且常常直接集成于编译器。我倾向于认为这些是较直接的工具。
蓝图与草图之间的界限颇为模糊，但是我认为，其区别基于这样一个事实即草图是轻完整性而强调重要的信息，而蓝图则意图综合全面，通常带有减少编程至一个简单的相当器械活动的目的。简言的说，我认为草图更具有探测性而蓝图则具有确定性。
因为你使用UML越来越多并且编程已经越来越机械化，很明显编程应该实现自动化。确实，很多用例工具做一些形式的代码生成，正是这自动的构建了一个系统的重要部分。然而，最终你将达到所有的系统都能够被UML描述的点，以及你延伸了UML使其能作为编程语言。在这一环境下，开发者绘制能直接编译成可执行代码的UML图，那么 UML则成为了源代码。很明显，这一UML的使用方式要求特别复杂的工具。（正向及反向工程的概念对这一模式也没有任何意义，因为UML和源代码是同一种东西）。
Model Driven Architecture and Executable UML
（模型驱动架构及可执行的UML）
当人们讨论UML的时候，他们也常常讨论模型驱动架构MDA。从本质上讲，MDA是将UML作为一种编程语言使用的一个标准方式。这一标准由OMG控制，也是基于UML的。通过建造一个建模环境使其遵从于MDA，生产厂商能创建模型使其能够与其他MDA集成环境工作。
MDA通常被作为与UML相提并论，因为MDA使用UML作为其基础建模语言。当然，你不必为使用MDA而去使用UML。
MDA将开发工作一分为二。建模者通过创建一个与平台独立的模型（PIM）描绘一个特别的应用。PIM是一个UML模型，它独立于任何特定的技术。工具能够将PIM转化为指定平台的模型（PSM）。PSM是一个系统的模型旨在适应于特定的执行环境。然后工具能进一步为特定的平台处理PSM及生产相适应的代码。PSM能够作为UML但是并不必要。
因此如果你想使用MDA建造一个数据仓库系统，你可以开始于创建一个数据仓库系统的PIM。然后如果你想让这一数据仓库系统运行在J2EE和.NET上。你将会需要使用一些厂商的工具来创建两个PSMs：每个平台需要一个PSM。然后更深入的一些工具将为这两个平台产生代码。
如果PIM到PSM到最终的代码这个过程完全自动化的话，我们将能够使用UML像编程语言一样。如果这些步骤中的任何一部要人工来完成，我们只是能够使用uml蓝图。Steve Mellor 长期活跃在这一类型的工作中并且近来使用了“可执行的UML”的术语。可执行的UML类似于MDA但是使用的是不同的术语。类似的，你可以开始于一个平台独立的模型，这一点等同于MDA的PIM。然而，下一步是在单独的一步中使用模型编译器将此UML模型转化为可部署的系统；因此并不需要PSM。正如未来编译器所建议的，这一步骤完全自动化。
模型编译工具都是基于可重用的原型。一个原型描述如何获取可执行的UML模型以及将其转化为特定的编程平台。因此对于数据仓库的例子，你将要购买一个模型编译器及两个原型（J2EE和.NET）。在你的可执行UML模型上运行每一个原型，你将拥有数据仓库系统的两个版本。
可执行的UML并没有使用UML的所有标准。很多UML的构造被认为是没有必要的而因此没有使用。结果可执行的UML比FULL UML要简单。
这些听起来都非常好。但是实际上是怎样？我认为在这里存在两个问题。第一个是工具的问题：是否足够成熟能够做这一工作。这是随时间而改变的。当然正如我所写的，他们并没有广泛的使用，实际上我并没有看见过很多这种工具。
一个更基本的问题是UML作为一种编程语言的全部概念。在我看来，使用UML作为一种编程语言是值得的只有在于其比其他编程语言能产生显著的多产。基于过去我所工作过的大量的图形开发环境而言，对此我并不确信。即使它是更多产的，它仍然需要获得决定性的多数使用者以使其成为主流。这是它自身的一个巨大障碍。像许多老的Samlltalk的使用者一样，我认为smalltalk 比当前主流语言更多产。但是现在这仅仅是一个没落的语言，我并没有看到很多的项目使用它。为了避免Smalltalk的命运，UML必须更幸运即使它很优秀。
一个围绕着UML作为编程语言的有意思的问题是：如何建模行为逻辑。UML2 提供了三种行为建模的方式：交互图，状态图及活动图。这三种都有使用他们编程的支持者。如果UML作为编程语言获得流行，那么看这些技术中哪一种取得成功将会很有意思。
人们看待UML的另一种方式是在概念上使用它以及在软件建模中使用间。大多数人对于UML使用于软件建模中很熟悉。在这一软件的视角中，UML 的元素相当直接的映射到软件系统的元素。正如我们即将看到的，映射并不是规定性的，但是我们使用uml的时候，我们实际上谈论的是软件的元素。
以概念的视角，UML则描绘了一个领域研究概念的描述。在这里，我们并不谈论软件的元素甚至连我们建造一个词汇来讨论一个特定域也不。
并不存在关于视图的硬性规则；事实证明，存在真正的大范围的使用。一些工具自动的将源代码转换为UML 图，将UML 看作是源代码的一个可选的视角。这真的是一个软件视角。如果你使用UML图尝试去理解具有大量含义的并带有一群会计师的术语资产池，你更多的只是了解UML概念的框架。
在这本书的之前版本，我将软件视角分割为规格说明书（接口）和实现。实际上，我发现很难给它们两个划清界限，因此我觉得它们的区别不值得再大惊小怪。然而我总是在我的图中倾向于强调接口而不是实现。
这些使用UML的不同方式导致了一系列的关于UML图的含义及它们与UML图之外的世界的关系的争论。特别是这影响了UML与源代码之间的关系。一些人认为UML 应该被使用来创建一个设计，这一设计独立于用于实现此设计的编程语言。其他人认为独立于语言的设计是矛盾的，只是着力于强调白痴。
另一个不同的观点是什么是UML的本质。在我看来，大多数的UML使用者，特别是草图的使用者，看待UML的本质将会是图。然而，UML的创建者认为图表是次要的，UML的本质是元模型。图仅仅是元模型的一种描述。这一观点对蓝图使用者及UML编程语言使用者同样有意义。
因此无论何时你读到任何设计到UML的东西，理解作者的观点的内涵是很重要的。只有到那时你才能理解那些对UML所支持的观点的激烈辩论。
说了这么多，我需要明确我的观点。大多数时间，我使用UML是作为草图。我发现UML草图对于正向及反向工程并且无论是在概念还是软件视角上都很有用。
我并不是一个详细的正向工程蓝图迷。我相信很难做好并且将会使开发的速度降低。子系统接口级别的蓝图是合理的，但即使是这样你应该对那些开发者通过接口实现交互的接口的改变做准备。反向工程蓝图的价值依赖于工具是如何工作的。如果将其作为动态浏览器使用，那将会很有帮助，如果仅仅是产生一堆文档，那么它所做的只是无用功。
我认为UML作为编程语言是个不错的注意，但是怀疑它将来是否能够得到重要的应用。对于大多数编程任务来说图形形式是否比文本形式更多产我并不能够确信，但即使是这样，这很难使一门语言得到广泛的接受。
由于我的偏见，这本书关注的主要是使用UML作为草图。幸运的是，这是一本有用的简要指南。而且我不能够以这本书这样的篇幅公正的讨论UML的其他形式。但是这样篇幅的一本书能够成为其他书籍的敲门砖。所以如果你对UML其他形式没有兴趣的话，我建议你把这本书看作一个引导，在你需要其他书的时候你也可以去看其他的书。如果你只是对草图有兴趣，这本书也许会满足你的所有需求。
1.3、UML的发展历史
我必须承认我是一个历史爱好者。对于轻松阅读我最好的想法是一本历史书，但同时我也知道这并不是每一个人寻找乐趣的想法。在这里我谈论历史是因为在许多方面，我认为没有理解UML如何到来的历史我们就很难理解UML在何处。
在20世纪80年代，“对象”开始从实验室中走出来并向“现实”世界迈出了第一步，Smalltalk被稳定到一个平台是人们得以使用，C++也诞生了。在那个时候，各种各样的人开始思考面向对象图形设计语言。
最关键的关于面向对象图形建模语言的书出现在1988年到1992年之间。领军人物包括Grady Booch[Booch,OOAD];Peter Coad[Coad ,OOA],[Coad,OOD];Ivar Jacobson (Objectory) [Jacobson，OOSE]; Jim Odell[Odell];Jim Rumbaugh(OMT)[
Rumbaugh,insights],[Rumbaugh，OMT];Sally Shlaer 及Steve Mellor[Shlaer and Mellor, data],[Shlaer and Mellor,states];以及Rebecca Wirfs-Brock（Responsibility Driven Design）[Wirfs-Brock].
这些作者中的每一个现在都非正式的领导一些喜欢他们观点的从业者。所有的这些方法都非常的相似，但是他们之间常常包含着一定数量的不同。相同的基本观点会出现非常不同的记号，而这导致了客户的困惑。
在这使人困惑的时刻，正如说的那样标准化被忽略了。隶属于OMG的一个团队尝试着标准化但得到的仅仅是所有关键的方法学家的一封公开的抗议信。（这是我想起了一个古老的笑话。问题：方法学家与恐怖分子之间有什么不同？答案：你可以同恐怖分子进行谈判。）
最初导致UML形成的激变事件是Jim Rumbaugh离开GE公司加入了Grady Booch所在的Rational公司（现在是IBM的一部分）。Booch与Rumbaugh的联盟最初被看作是能够获得市场份额的临界事件。Grady和Jim宣称“方法战时代已经结束-我们赢了”。基本上是宣告他们将要达到标准化。“微软的方式。” 一些其他的方法论学者建议形成一个反Booch联盟。
到OOPSLA’95的时候，Grady与Jim已经准备好了方法合并之后的第一次公开描述:统一方法的文档版本为0.8。还有更重要的，他们宣称Rational软件已经购买了Objectory，从那以后Ivar Jacobson将会加入统一团队（Unified team）。Rational主持了一个有众多人参加的关于发布0.8版本草稿的宴会的庆典。（这一宴会的亮点是第一次公开展示了Jim Rumbaugh的歌喉；我们希望这也是最后一次）。
下一年出现了一个更开放的进程。OMG这个曾经大多数时间在旁观的组织，此时正承担着一个活跃的角色。Rational不得不整合Ivar的观点同时得花时间整合其他伙伴的。更重要的是OMG决定担当主要的角色。
在这一点上，明白OMG为什么参与进来是很重要的。方法论者，例如书的作者们，喜欢认为他们是重要的。但我认为OMG并没有听到那些作者的尖叫声。真正是OMG参与进来的是工具生产厂商的尖叫声，这些厂商都非常担心标准被Rational公司所控制，这将会给Rational工具取得一个不公平的竞争优势。因此厂商激发OMG在（用例）Case工具的互操作性标语之下去做一些事情去阻止。这一标语是重要的因为OMG谈论的都是互操作性。创建UML的观点将会使得Case工具能够自由的互换模型。
Mary Loomis及Jim Odell主持了初步的工作。Odell明确了他不准备使他的方法称为标准，但是他并不想要一个被Rational所影响的标准。在1997年一月，各种各样的组织提交了关于方法标准的建议以利于模型的互换。Rational协助其他组织机构并如他们所建议的发布了UML文档的1.0版本，第一次回答了此物的名称统一建模语言。
然后在各种不同力量交织的短期内，大量不同的建议终于合并。OMG采纳了最终版本1.1作为OMG的官方标准。一些修订仍在继续。修订版1.2完全是表面的。修订版1.3的修订更重要。修订版1.4加入了一些详细的围绕着组件及配置（Profiles）的概念。修订版1.5增加了动作语义。
当人们讨论UML的时候，他们大多认为Grady Booch，Ivar Jacobson，及Jim Rumbaugh是创始者。他们通常被称为三友，虽然说话是要下降第二个单词的第一个音节。虽然他们相信UML，但是我认为某些时候给三友绝对的信任是不合理的。UML的标记符第一次形成是在Booch及Rumbaugh的统一方法中。从这之后，大部分的工作都由OMG委员会领导。在这最后的阶段，Jim Rumbaugh是这三个中唯一一个做了重要的贡献的。我的观点是UML委员会的这些致力于UML的成员值得得到主要的荣誉。
1.4、标记符及元模型
当前状态的UML定义了标记符以及元模型。标记符是存在于模型中的图形的内容，它是建模语言的图形语法。例如：类图标记符定义项及概念如类、协作、多重性等是如何表示的。
当然，这引起了对于协作及多重性甚至一个类的精确含义的质疑。常见的惯用法提出了一些非正式的定义，但是许多人希望比之更严密的定义。
在正式方法的领域中有严格的规范说明和设计语言的观点最流行。在这样的观点中，设计、规格说明都是表示使用如术语微积分的导数。这样严格的数学定
义且不允许含糊。然而这些定义根本不通用。即使你能够证明一个程序满足数学规定，但并没有任何方法去证明这一数学规定满足系统的真实需求。
大多数图形建模语言并不严密。他们的标记符倾向于直觉的东西而非正式的定义。大体而言，这看起来并没有什么害处。这些方法也许是非正式的，但是许多人仍然发现他们很有用——有用才是重要的。
而方法论者都在寻找一种方法：在不牺牲他们的实用性的前提下去改进方法的严密性。一种路线是定义一个元模型：一个图，通常是使用一个类图类图定义这种语言的概念。
Figure1.1这是一个UML元模型的小片段，展现了各种特征之间的关系（精华是让你尝尝UML元模型的味道。甚至我不想尝试解释它）。
Figure1.1 A small piece of the UML meta-model
（uml元模型的微小片段）
元模型能够在多大程度上影响一个建模标记符的使用者？这个问题的答案总体上要依据惯用法的使用方式。草图者使用时并不怎么注意使用方式；蓝图者应该比草图者更在意。对于那些把UML作为一门编程语言的使用者来说使用方式是最重要的，因为它定义了这种语言的抽象语法。
大多数参入UM持续发展的人，主要是都对元模型有兴趣，特别是它对UML及编程语言的使用方式是非常重要的。标记符的问题通常放在次要的位置，如果你想要熟悉标准文档本身的话，请谨记这一点。
如果你更深入了UML的更详细的用法，你会意识到你需要比图形标记符更多的东西，这就是UML工具如此复杂的原因所在。
在这本书中我并不打算使用严格的方式。我将使用传统的方式，主要让你通过直觉来了解它。这对于一个主要倾向于使用草图惯用法的作用来说，使用这种方式写一本小篇幅的书是很自然的。如果你喜欢更严格的方式，你应该去参阅更详细的宝典。
1.5、UML图
UML 2中描述了被列在表1.1中的13种正式图，我们可以按照图1.2的方式将它们分门别类。虽然这些图是许多人学习UML以及我组织本书的方式，但是UML的创始者并不认为这些图是UML的核心部分。因此，这些图的使用并不严格。通常你可以在一种图上使用另一种图的元素。UML的标准指出某些特定元素的典型用法使用在一定的图中，但这并不是强制性的。
图1.2 UML图的种类
Table 1.1.UML正式图的种类
Diagram Chapters Purpose 引进版本
活动图 11 过程及并行行为 UML 1
类图 3，5 类、特征及关联 UML 1
通信图 12 对象间交互；重点在于对象间链接 UML 1协作图
组件图 14 组件间的组织结构及连接 UML 1
组合结构图 13 运行时类实例形态 UML 2
部署图 8 将制品部署到节点 UML 1
交互概况图 16 序列图与活动图的混合 UML 2
对象图 6 实例形态的举例 UML1非官方
包图 7 编译时的分层结构 UML1非官方
序列图 4 对象间的交互；强调序列 UML 1
状态机图 10 事件在对象的周期内如何改变状态 UML 1
时序图 17 对象间的交互；强调时序 UML 2
用例图 9 描述用户与系统如何交互 UML 1
1.6、什么是合法的UML
咋一看，会认为这应该是一个很容易回答的问题：合法的UML应该是在规格中有良好定义的东西。然而，事实上，答案略微有些复杂。
这个问题一个比较重要的部分是要清楚UML是否有描述性或法定的规则。一门语言的法定规则由官方团体所控制，这个团体规定在语言中什么是合理的，什么是不合理的以及你使用该种语言的表达的意义为何。具有描述性规则的语言就是你可以通过观看其他人实际怎么使用他们来理解它的规则。编程语言倾向于拥有法定规则，这一规则通常由标准委员会及主导厂商设定，而自然语言比如英语倾向于拥有描述性的规则，它的意义往往是约定俗成的。
UML是一门非常精确的语言，因此你可能会期待UML有自己的法定规则。但UML通常被认为软件中同与其他工程学科的蓝图相当，这些蓝图并不是法定的标记符。没有委员会规定在结构工程绘图中什么才是合法的样式。与自然语言类似，标记符往往也是俗成的。仅仅一个标准，很难达到理想的效果。因为在这个领域的所有人不可能会遵照标准的所有方面。正好去问法国人关于法国科学院。另外UML如此复杂，所以标准通常以多种方式解释。甚至那些审阅了这本书的UML创始者也对UML标准的的解释持有不同观点。
这个问题对于我写这本书以及你使用UML是都很重要。如果你想理解UML图，认识到理解UML标准并不能了解所有的事情是非常重要的。人们采纳约定，不仅在工业上很普遍，在一个特别的项目里也一样。因此，虽然UML的标准是了解UML信息的最主要的来源，但是这并不是唯一的来源。
我认为，对于大多数人来说，UML具有的是描述性的规则。UML标准对于UML意味着什么的影响是首屈一指的，但是它并不是唯一的影响。我想这一点在UML2中变得特别正确，UML2中引入了一些俗成的标记符，这些标记符不仅与UML1的定义而且与UML的一些惯用法有冲突，同时对UML增加了一些复杂性。因此，在这本书中我尝试着按我所研究的去总结UML。我将使用术语“约定用法”去展示一些在UML中广泛使用的但是UML标准中不存在的东西。
其中如果符合UML标准，我将使用“标准”或“规范化”的术语（人们使用“规范化”术语来表明你必须遵行UML标准以使自己合法。因此非规范化的UML是以一个非常美好的方式来表明它并没有严格遵循UML标准。）
当你在看一种UML图的时候，应该牢记一个准则：任何信息在UML中都有可能被UML图所隐藏。
这种隐藏通常会发生在——隐藏所有的属性——或者明确的——不展示这三个类。因此在图中你不能因为它的缺失而推断其它任何事情。如果多重性的值缺失，你不应该去推断它可能的值。即使UML元模型都有默认值，例如属性通常默认值为1，如果你在图上不能够找到相应的信息，也许可能是因为它是默认值或是被隐藏了。
话虽如此，这里通常有一些约定俗成的内容，比如设置多值属性。在文中，我将指出默认的规则。
如果你习惯于素描或蓝图，没有必要过分强调UML的合法性，而更重要的是使你的系统有一个良好的设计。我倾向于虽不正规的UML但有一个良好的设计的系统而不是虽然UML使用的很规范，但是是非常差的设计。很明显良好而又规范的设计是最好的，但你应该专注于拥有一个良好的设计而不是去考虑UML的奥秘。（当然，你应该合法的使用UML作为一种编程语言，否则你的程序不会顺畅的运行。）
1.7、UML的含义
与UML有关的一个比较尴尬的问题是：虽然规格说明书中详细描述了良好的UML的形态，但是对于在UML元模型外部的纯纯世界UML到底意味着什么，却没有什么可说的。没有UML怎样映射到一种特定编程语言的正式定义存在。光看着UML图，我们不能精确的了解与之等同的代码到底是什么样的。然而，你可以粗略的感受到代码将会怎样。实际上，这已经足够有用了。开发团队常常基于此形成他们的固有惯例，你将需要熟悉它们所用的惯例。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
