 > 建模 > UML >
> 建模 > UML >
UML 中文 FAQ
阅读数:81.4K 基本历史
第二部份 UML 高级话题 第三部份 UML 应用 UML 有哪些特点？概括而言，UML 建模语言具备这样一些特点：通用性、可视性、抽象性、实用性、 统一性 、灵活性、 可扩展性和 广泛性 等等 ... （像不像软件质量属性？其实 UML 本身也是一种“软件”） UML 的“通用性”主要是指不仅仅可以用它来描述软件， 而且还可以用它来描述一般企业或组织的业务流程以及由软、硬件共同组成、以软件为主的复杂系统 （即所谓的软件密集型系统），甚至还包括非软件系统。 UML 的“可视性”是指可以通过 UML 一系列的图形符号， 组成多种视图（view）来直观、清晰地表达系统分析设计中方方面面的、许多复杂的概念。 UML 主要是为了方便人们的阅读和使用而设计的， 所以它采用了形式化或半形式化的、易于人们理解和交流的形式。 UML 是一种分析设计专用的抽象建模语言，它本身不是编程（programming）语言或实现级别的语言。 目前 UML 还不能直接执行，也不是一种严格意义上的程序语言，却可用它来生成可执行的程序框架。 UML 是一种比 C、C++、Java、VB、Delphi 等文本高级语言抽象层次更高的图形语言， 通过它我们可以抽象地表示用高级编程语言编写的文本程序的逻辑结构和行为。 相比传统的第三代、第四代高级编程语言（3GL、4GL），UML 能够更加高效、准确地反映软件设计的方案和思路， 在当代软件工程中，UML 是被真正用来“设计程序/高级程序”（design the programs）的语言。 从这个意义上看，不妨可以称之为“甚高级”或第五代程序设计语言（5GL）—— 鄙人之陋见。 UML 基本上不能算作一种全新的发明，而且作为一项产品，它也并非来自学者教授、科研机构理论性研究的最新学术成果， 而是直接来自于产业界、工程界的实践总结，它是在软件工业实践归纳基础上进行理论升华的产物， 其核心内容反映了 30 多年来全球软件工业的领导者在软件分析、设计和构造领域的最佳实践和成功经验， 因而具有很高的实用价值。 实践证明，作为对象技术的核心，面向对象分析设计（OOAD）方法比传统方法能更加准确、 全面地描述物理现实世界和由逻辑概念构成的虚拟软件世界。UML 是用来表述 OO 概念的一种语言工具， 而很奇妙，它本身作为一件产品同样也是由 世界级软件大师们 用 OO 方法设计出来的， 这使得 UML 具有传统建模语言所不具备的极强的语法语义表达能力和非常灵活的可扩展性。 UML 有什么用？UML 的用途非常广泛，可以概括为“描述、可视化、构造、记载”四种基本功能， 在软件开发全生命周期的各阶段任务中，如业务建模、需求分析、系统设计、实现和测试、数据建模、 项目管理等，均可根据需要采用。 UML 建模是建立软件开发文档非常有效的一个手段，通过 UML 图形可视化地描述系统需求，记载软件构成， 能够显著地提高文档的质量和可读性，减少文档编写的工作量。 UML 实质上是一种系统分析设计专用语言， 通过可视化的图形符号结合文字说明或标记可以帮助业务/系统分析员、软件架构师/设计师、 程序员等各种建模者有效地描述复杂软件（或业务）的静态结构和动态行为，包括工作流（数据流和控制流）、 功能需求、结构元素及关系、架构组成、设计模式、对象协作、事件响应和状态变化等等。 UML 是描述软件设计模式（Design Patterns）最常用和最有效的标准语言。 UML 不能做什么？UML 不是高度形式化的语言，一般不能用于定理证明。 UML 是基于面向对象（OO）方法的通用建模语言，目前不适合用户图形界面（GUI）设计、 超大规模集成电路（VLSI）设计、基于规则的人工智能等专业领域。 UML 是一种离散型建模语言，适合对由软件、固件或数字逻辑构成的离散系统建模， 不适合对工程和物理学领域中的连续系统建模。 作为语言（language），UML 本身仅仅是一种表达形式，不是建模方法（method）， 在实际的软件项目开发中仅仅掌握一套标准的图形符号是远远不够的。 用好 UML 首先需要掌握 OOAD 的基本原则和方法，并在一定的软件开发过程 （如统一过程 UP/USDP/RUP/AUP、XP 等）的指导下进行有取舍的运用。当然，有时候我们也会说“UML 方法”，这是 指“采用 UML 建模的开发方法”或者“UML 的建模方法”。 为什么要学习和掌握 UML ？我们认为 UML 对于当前大多数希望进一步改进质量的软件开发团队来说是 必不可少或必须 的。 为什么这样说呢？因为， C++、Java 等源码并不能直观、方便地反映复杂程序的设计： 如内部逻辑结构、各种隐含的依赖关系、运行时的状态改变和特殊行为等等。 程序员编写出来的代码仅仅是一种可行的实现方式，很难反映出现象背后的真实本质 —— 软件的设计原理或算法，因此对于大多数稍稍复杂点的项目来说，仅有代码是不够的。 可视化建模历来是一种行之有效的最佳工程实践，并非软件行业所特有。 软件的设计方案在用 C++、Java 等编程语言实现之前，通常隐藏在人们的头脑当中，C++、Java 程序是人们思考的结果产物。而解决方案的设计正确与否是决定解决方案本身及软件质量优劣的根本。 为了保证一个复杂设计方案的正确性，我们最好在实现它之前，用简洁和恰当的方式把设计表达出来。 相较于含混的大脑模型和冗长的程序代码，经验老到的程序员发现对图形化的软件设计模型进行验证往往是一种更为 高效和可靠的工作方式。 事实上通过程序代码来表达、讨论、评估和选择复杂软件的设计往往是很笨拙的， 这一表达方式的空欠唯有通过像 UML 这样的比具体的程序语言/实现语言更高层次的、更抽象的建模语言来填补。 OO 方法是当代主流的软件开发技术。 世界先进的软件团队和个人早已摆脱了对如何使用具体的平台 API、个别编程语言特性的纠缠， 把更多的精力放在了需求、架构、设计机制和模式等对软件质量有重大影响的核心要素 —— 分析与设计上， 因而成功开发出了规模越来越大、复杂度越来越高、质量越来越好的软件产品与系统。 UML 作为工业界 OO 建模语言的事实上标准和主要的表达媒介， 在软件的分析、设计、架构和模式表达这些场合能发挥关键的作用。 所以，熟练地掌握并运用好 UML 是当今项目主管、系统分析员、 架构师/设计师以及高级程序员等软件工程人员所必备的一项基本技能。 什么情况下应该用 UML ？对于一个特定的软件开发机构或团队，在下列情况下建议采用 UML： 1）OO 方法是项目决定采用的工艺，是整个项目或产品成功的关键； 2）开发人员感觉用源码说明不了真正的问题，希望利用可视化建模语言简化文档，提高交流的效率，准确抓住问题的本质； 3）系统的规模和设计都比较复杂，需要用图形抽象地表达复杂的概念，增强设计的灵活性、可读性和可理解性，以便暴露深层次的设计问题，降低开发风险； 4）开发组织希望记录已成功项目、产品的公共/通用设计方案，在开发新项目时可以参考、重用过去的设计，以节省投入，提高开发效率和整体成功率。 5）有必要采用一套通用的图形语言和符号体系描述客户组织的业务流程和软件需求，促进业务人员、软件开发人员之间一致、高效的交流。 促进 UML 普及和应用对于加强我国软件业的实力有什么重要意义？面向对象（OO）方法自上世纪 80 年代以来已经成为软件开发的主流技术，标准 OO 建模语言 UML 的问世说明 OO 技术的发展达到了一个新的高峰。推广普及 UML 的应用可以使我国软件开发人员、 软件企业和 IT 客户乃至整个行业、产业都从中获益： 1）个人：UML 相关知识体系蕴含了非常丰富的当代软件工程先进知识。软件开发人员通过学习和掌握 UML 概念、 表示法及相关的软件过程、软件工程技术，能够加深对 OOAD 原则、方法的理解，提高抽象思维能力， 从而站在更高的层次上分析问题、解决问题，这是一条快速提高个人面向对象软件设计能力的有效途径。 2）企业：对软件企业内部，用好 UML，不但能直接提升企业的软件设计开发能力，而且由于 UML 能形象直观地记 录软件设计的核心思想，可以使软件开发管理透明化，促进企业知识资产的保护和增值， 促进软件重用和整体效益的大幅提升。对外，由于 UML 是通行的软件行业国际标准， 企业在业务交往中有效运用 UML，无论对于开拓国内外产品市场还是保障工程承接、 项目外包等业务的顺利开展都大有裨益。 3）行业：积极采用国际通行的软件描述和设计语言 UML，一方面能增加信息透明度，显著降低软件企业之间、 客户与开发商之间的沟通成本，减少项目失败的风险，另一方面能促进行业市场的规范化和标准化， 增进国际技术交流，整体提高我国软件业的技术水平和参与国际市场竞争的能力。 UML 的统一性表现在哪些方面？UML 的统一性至少表现在以下几个方面： 1）随着对象技术的蓬勃发展，到上世纪 90 年代初据报道 OO 建模方法已经多达 50 余种， 它们之间既有很多共通之处也存在许多没有必要的细节差异，这妨碍了技术进步，不利于产业的发展。 UML 统一了多种互补的、最具代表性、最受业界欢迎的主流 OO 方法，这既是历史的必然，也是 OO 方法成熟的一个重要标志。UML 及与其配套的软件开发统一过程（UP）在实现“合并同类项”的基础上又向前迈出了 一大步，不愧为当代 OO 建模方法的集大成者。 2）UML 适用于各个行业的信息化工程和产品系统开发，包括电信、银行、保险、税务、办公自动化、电力、 电子、国防、航天航空、制造、工业自动化、医疗卫生、交通、商业、电子商务等诸多领域的业务建模和 软件分析设计，尤其适合对大中型、复杂、分布式应用系统或软件产品建模， 在这些广泛的领域中都可以统一使用这一套标准的建模语言。 3）作为一种独立于具体实现的、抽象的表述方式，UML 广泛地适用于各种现代程序设计语言、 数据库和开发平台。 4）有了 UML 标准，面向各种不同的软件开发方法和过程（如重载/轻载，瀑布式/迭代递增式）， 在软件开发生命周期各个阶段的工作（如业务建模、需求分析、系统设计、实现、测试）中， 都可以采用一套统一的概念和表示法，避免了语言转换的麻烦。 5）UML 明确定义了一套公共的内部概念，建立了统一的关于建模语言的元模型， 反映了在软件和信息建模技术领域的最新成果。 UML 是如何诞生的？识时务者为俊杰。为了打破上世纪 90 年代初 OO 方法论、图形化软件建模语言混战的局面， 1994 年杰出的 Rational 公司的 OO 大师 Grady Booch 邀请通用电气（GE）公司的 OO 大师 James Rumbaugh 博士加盟 Rational，启动了 OO 方法的统一历程。他们于 1995 年发表了“统一方法 0.8”, 与此同时另一位 OO 大师 Ivar Jacobson 博士也在该年加入了他们的行列。 1996 年，三人正式把他们的统一成果命名为“统一建模语言”，UML 于此诞生。 同时，他们与 Rational 公司还做出了一个非常重要的决定 —— 把 UML 提交到非赢利性的国际对象管理组织 OMG 进行标准化， 让全世界的软件开发人员都可以自由地分享这一软件史上的重大成果。 于是，在全球软件界具有广泛影响力的 OMG 从此开展了一系列 OO 建模语言的标准化工作。1997 年 11 月，UML 1.1 经 OMG 各成员投票被正式采纳为 行业推荐标准。 UML是一家之言或少数派的观点吗？否， UML 是全球软件工业界和学术界的领导者协同努力的成果。 UML 标准化促进了各种 OO 方法和流派的大融合，在 OO 建模语言领域具有不可替代的地位。 自从进入 OMG 程序后，UML 就不再由 Rational 一家公司所有或由少数人控制，而成为凝结了百家之长的公共知识结晶。 这里举两个例子。 具有丰富企业信息系统和信息工程经验的 OO 大师、Martin/Odell 方法的领军人物 James Odell 为此曾表明放弃自己的方法，并直接参与领导了 UML 1.x 系列标准的制订工作。 另一位 OO 大师 Coad/Yourdon 方法的创始人之一 Peter Coad，虽然没有直接参与 UML 制订， 但却独具慧眼创办了 TogetherSoft 公司（如今已被 Borland 收购），开发了著名的 UML 集成开发环境 Together ControlCenter。 UML 的形成和演化过程是国际软件工程界一次盛况空前、史无先例的大团结和大合作， 可谓群英荟萃，星光灿烂。对 UML 标准作出重要贡献的大师级人物，除了以上介绍的， 大家比较熟悉的还有 Cris Cobryn, Ward Cunningham, Bruce Douglas, Martin Fowler, 四人团 Eric Gamma 和 Richard Helm, Ralph Johnson, John Vlissides, David Harel（状态图的发明人）, Robert Martin（Bob 大叔）, Bertrand Meyer, Bran Selic, Rebecca Wirfs-Brock, Edward Yourdon 等等， 世界级的专家贡献者实在是太多了，在此不可能逐一细述，我将在以后的文章中陆续向大家介绍。 UML 之父是谁？UML 之父有三位，分别是：Grady Booch（Booch 方法发明人），James Rumbaugh（OMT 方法发明人）和 Ivar Jacobson（OOSE 方法发明人）。 人们亲切地称他们为“3 amigos”（即“三友”或“三高”，类似于大家给予联手举办世纪音乐会的世界上 三位顶尖男高音歌唱家的称谓）。 UML 标准有哪些最新进展？UML 1.x 系列的最新版本是于 2003 年 3 月发布的 1.5 版本。 OMG 从 2000 年起启动了 UML 2.0 标准的制定工作。 U2P 组织（UML2 Partners Consortium） 在 UML 2.0 标准的制定过程中发挥了主导作用。UML 2.0上层结构（Superstructure）规范在 2003 年 6 月 12 日 获得通过标志着 UML 2.0 标准研制的成功，目前对所有相关文件的扫尾工作也即将结束，UML 2.0 将于 2004 年夏季正式发布。 初学者如何开始学习 UML ？我想无外乎有这样几种方式：读书自学、上网交流、参加培训，以及最关键的 —— 亲身实践。 最近几年国内出版引进了不少与 UML 有关的中英文书籍， 但说实话，有点良莠不齐，初学者不管自学还是参加培训，选择合适的 UML 教材/读物是很重要的。 Craig Larman 的《UML和模式应用》是一本非常好的内容丰富、真正实用的入门教材， 在国际上可能也是用得最多的一本。纵观全书，以实案为中心，脉络清晰，组织老到，深浅适当，循循善诱， 非常适合 UML、UP、设计模式的初学者，以及那些一直对 OOAD、UML 的价值存有疑虑的、传统结构化人士一读。 对于熟悉 OO 的人来说，阅读此书也是再一次享受梳理知识、进行系统性训练或回顾的美妙体验。 如果希望与大师对话，全面深入地掌握 UML 的基本要领，通过领悟 UML 设计者的思想和意图来达到在实战中 得心应手运用 OO 建模技术的目的，建议阅读 UML 之父亲自撰写的《UML用户指南》。 本书相当全面，偏重理论分析和概念阐释，这些内容和抽象技术对于真正理解 UML 是非常基本、必不可少的， 它适合喜欢认真探究一切的读者。 用好 UML 离不开有好的过程作指导。RUP 极其丰富的内容令初学者生畏，Ivar Jacobson 在《统一软件开发过程》 一书中从管理者和系统架构师的角度，通过实例分析系统地讲解了将 UML 用于分析设计实践的完整过程， 深入浅出，言简意赅，可以说此书正是 RUP 的精华所在。带领自己的团队用好 UML，此书不可漏矣。 UML 标准规范、《UML参考手册》内容深、篇幅大，主要面向 UML 工具开发者、专家和研究人员，不推荐初学者阅读。 国内外不少专业网站还提供了非常丰富的学习资料和参考文章，可以有选择地进行学习。 世界上有哪些著名的企业和组织机构参与了 UML 标准的制订？历年来，参与 UML 标准制订的一些核心企业和组织机构包括（1.x、2.0）： 全能型 IT 公司：HP, IBM, Sun, Unisys 大型软件公司/ISV：CA, Microsoft（1.x）, Oracle 软件开发/软件工程工具供应商：Artisan, Borland, Compuware, Embarcadero, Gentleware, I-Logix（已被 Telelogic 收购）, Jaczone, Mercury Computer, Popkin, Rational（已被 IBM 收购）, Telelogic 通信设备开发商： Alcatel，Ericsson，Fujitsu，Motorola 软件行业组织：OMG IT 系统集成商/咨询公司：EDS, Intellicorp 行业客户：Daimler Chrysler, Lockheed Martin, France Telecom 等等。参与制定并直接支持 UML 2.0 标准的国际知名企业、院校和机构多达 53 家以上， UML 在业界的影响力和地位由此可见一斑。
class Customer
{
private List<Order> _orders;
...
}
class Order
{
private Customer _cus;
public Order(Customer cus);
...
}
但这常常很难说清楚。我常常试着从 UML 序列图来加以判断，从对象的动态协作分析，只有到某个类确实需要引用到另一个类的时候才会把这样的引用加上去。但是有的时候好像也说不太清楚，感觉是一件很钻牛角尖的问题。
比如上面的例子，似乎 Customer 不需要了解 Order，但是像操作 AddOrder(Order), DeleteOrder(OrderID) 交给谁好呢？而 Order 需要引用到 Customer 的原因是，比如在打印 Order 的时候，如 Print(Order o)，Order 对象显然应该知道它所属的 Customer 是谁。 是不是我的理解有所偏差呢，请张老师指点一下，或者有这方面的资料、书籍可否推荐，谢谢。 答： GouGou，你好！决定设计类关联关系的导航方向，是单向关联，双向关联，还是没有关联，其实这些都是可选方案，确定采用哪种关联以及关联的方向，完全取决于你对软件的设计，也就是说，这些都是人为的。当然，对于最终设计结果，我们还是有一个判断准则：比如，结果设计类图是否做到了高内聚、低耦合，是否能够实现方便的类访问，执行效率如何、扩展性如何等等。 从你给的以上例子 Customer-Order 代码看，你在这两个类之间建立了一种紧密的聚合关系（Aggregation）：Customer 聚合了多个 Order 对象（一对多），而每个 Order 对象又与一个 Customer 对象关联（一对一）。这当然是一种可行的设计方案。这种双向关联关系（聚合是一种强关联）的好处是访问比较方便，从两个导航方向都可以轻松获得所需要的信息/数据。缺点是什么？构造/建立这样一种双向关联关系比较麻烦一点，至少需要两次对象初始化，以保存对关联对象的引用。而且，两个设计类之间直接建立这种双向关联，就形成了紧耦合，对其中一个类的改变会影响到另一端的类对它的引用。 单纯从这两个类看，采用单向还是双向关联，好像都是对的，只要能够实现软件功能而且访问对象方便，本无所谓。要最终判断这个设计好不好，我建议把考察边界扩大一点，也就是考虑你的软件中 Customer-Order 周边的对象，看看其他对象是如何使用它们的，比如，在用例（use case）功能的实现路径上考察这两个对象的导航关系，这样我们就能更全面地作出判断。 你根据序列图（sequence diagram）来判断是否需要某个方向的关联，这也是一种正确的做法。问题是，有的时候，我们不会在设计时把所有的序列图都完整地画出来，这时候就需要运用、结合其他方法来判断了。 关于 Customer-Order 之间应该建立双向关联，你给出的两条理由也是对的，这当然也是一种可行的判断依据。既然有充分的理由，就可以建立双向关联。 事实上，两个类之间有没有、该不该建立关联关系这件事情本身，比这个关联的导航方向，是单向，还是双向，更为重要。前者为主，后者为次。即使导航方向错了，也没关系，毕竟你还可以轻松重构么。因此在实践中，尤其在敏捷建模和架构设计的时候，我们往往只在两个类之间画上表示关联的连线就足够了，而不必过分关注导航箭头的方向，这是一个不太重要的细节。当然，如果你有充足的理由可以肯定正确的导航方向，也可以在设计类图中直接标明；如果不能马上确定，我建议推迟决策，先假定双向都可以访问，然后等到编码时或者掌握足够判断依据时再明确指定和重构。 另外还有一种判断方法，是从 OOA（面向对象分析）层面考虑。作为分析类（不同于你所说的设计类），Customer-Order 类之间是否应该建立关联完全取决于业务的需要。很多时候分析模型对于你的 OOD 和程序设计可以起到借鉴参考作用。比如，如果业务要求，从每张订单 Order 中，都可以知道该订单来自于哪位客户 Customer，那么在分析模型中 Order 必然有一个关联指向 Customer。另一方面，是否每个 Customer 都能知道他下了哪些订单呢？我们不知道，这要看具体业务和应用环境的需要。 OOA、OOD 会影响我们的面向对象程序代码，而 OOD 包括设计类图的导航关系可以参考 OOA 分析的结果。这样，就不会出现类似“Customer 不需要了解 Order”这样模棱两可的问题了。“Order 对象应该知道它所属的 Customer 是谁”，你的这一结论其实正是来自于业务分析，也就是在实际的订单上有客户的名称，这样你在打印的时候自然需要知道而且标明客户是谁了。 我们的设计其实最终都来源于需求，服务于需求。如果设计类 Customer-Order 之间不建立任何关联，也能满足需求和用例功能实现的需要（请考虑这种情况是否有可能存在？），那么这就是最优的、最简单的设计。我的意思是说，事实上不存在绝对完美（100% perfect）的设计，OOD 要因时因地，也就是根据具体的 Application Context 而定。一种好的设计换一个应用环境，可能就变成了差的设计。这就是我的太极 OO 思想的一种观点。 小结一下： 关于两个设计类之间的导航方向问题，这并不是一个牛角尖问题，可以有很明确的答案。当然，这需要你要根据一定的设计原则和应用环境来思考，作出决策，以能否使结果程序代码更简洁、更高效、更灵活等质量要素为最终判断依据。掌握 OOD 的基本原则（比如高内聚、低耦合等等），以不变应万变，这才是 OO 设计的关键所在。 不知道你对 OOA、OOD 的概念和设计原则是否很熟悉，建议你仔细看一下《UML 用户指南》或者 Larman 的《UML 和模式应用》，里面有较详细的关于关联关系、OOD 设计原则的探讨。感谢你的提问！
 |
