UML学习

目 录

• 为什么重要
• 学习旅程
  • 视图和图
  • 相关资源
  • 聚合、关联和引用
• 实践建议

---

为什么重要

您应该使用UML吗？一个字：是！……新的书、文章等等将会全部以UML作为符号。……如果你正要开始使用建模符号，您就应该直接学习UML。

—— Martin Fowler 1997

统一建模语言UML（Unified Modeling Language）是一套用于面向对象系统建模的标准符号，在20世纪90年代几经波折，终于得到对象管理组织OMG（Object Management Group）的支持，成为业界符号系统的统一标准。

因此，了解它是学习后面技术的前提。这并不是夸张，在看懂（并非精通）UML以前，我压根没明白《设计模式》，因为《设》里面就用到象UML那样的语言——OMT。

那UML无疑是重要，但它能很好的胜任建模工作吗？关于这个问题，我没有能力给您一个完美的答复，相关的“讨论”也在继续，但下面的几个事实相信会给您信心。

1。UML吸取多种建模语言的优点，包括三位全球顶级方法学家的贡献。

2。它在风雨中崛起，经受考验。

3。UML得到OMG组织及其成员的支持。

4。相当多的业界巨头们也在使用着它。

---

学习旅程

UML体系是如此复杂，可能会让您觉得难以把握。但是我们只要有选择性的学习就足够了，剩下的当日后有需要时再深入研究。

在学习之前，我们先来做一个说明，UML仅是一门语言，学习UML不等同于学习系统建模，它们的关系就好比学习中文和学习文章写作那样。只是很多情况下，我们都会把它们联系在一起而已。

---

视图和图

那好，就让我们开始吧，先来浏览一下UML的全貌。由于我们很难只从一个角度去完整描述一个系统的所有方面。因此UML提供了以下五种视图，它们分工合作，又互相补充。

1)    用况视图（Use Case View）

2)    设计视图（Design View）或逻辑视图（Logical View）

3)    进程视图（Process View）

4)    实现视图（Implementation View）或组件视图（Component View）

5)    实施视图（Deployment View）

而这五个视图又分别用到以下九种图中的一种或几种。

1)    用况图

2)    类图

3)    对象图

4)    顺序图

5)    协作图

6)    状态图

7)    活动图

8)    构件图

9)    实施图

---

相关资源

好，看一下相关资源。

1) 《UML用户指南》

此书出自名家，只是部分翻译欠佳。阅读时弄清楚上述五个视图的概念和几种常用的图的表示即可，初次阅读不必深究。

2) 《UML和模式应用》

书中示范如何结合UML以增量方式开发一个系统，着重介绍了OO分析的技巧和法则。内容稍嫌罗嗦，但不失为一本好书。

3) 《UML Distilled》

另一本入门好书，作为普通使用已经足够。

4) 《非程序员》第二期之《用UML设计Java应用程序》

阅读这一短篇文章，可以快速了解如何在实际项目中使用UML。

5) http://www.uml.org/

UML的官方网站，可以找到很多有用资料。

6) http://www.umlchina.com/

它发行《非程序员》电子杂志和记录很多中文文档，还有一个非常活跃的讨论组。

7) http://www.csdn.net/develop/

8) http://www-900.ibm.com/developerworks/cn

这两个网站可以搜索到很多UML的中文文章，只是比较零散，不大适合系统学习。

再来看一下UML工具。在这方面我没有很好的经验，且看看别人怎么说。

1) 《非程序员》第一期的“选择一种UML建模工具”介绍了评价UML工具的一系列标准。

2) UML官方网站资源页的“UML Tools”栏（链接）列出了极多的UML工具，可供选择。

---

聚合、关联和引用

最后，我们讨论一下几个具有“争议”性的概念——聚合（Aggregation）、组合（Composition）、相识（Acquaintance）、关联（Association）、依赖（Dependence）和引用（Reference）。它们极具相似性，在代码的实现上有些甚至是完全一样的，然而从概念上理解和区分它们对我们的系统分析和设计是有重要意义的。

聚合是指一个对象拥有另一个对象，仅强调“拥有”。而组合是指一个对象是另一个对象的一部分，强调“不可分割”，两个对象具有相同的生命周期。两者的差别就好比创立一间公司时您可以不要雇员（拥有），但创造一个人时您却不能丢掉了他的心（不可分割）。

关联和依赖都是指一个对象知道另一个对象。区别在于关联是一种结构关系，表现为一个对象能够获得另一个对象的实例引用并调用它的服务（即使用它）；依赖是一种使用关系，表现为一个对象仅仅是调用了另一个对象的服务。相识既可能是关联，也可能是依赖。

引用是指那些指向对象的类属性。实现组合、聚合和关联时无可避免的要用到引用，但实现依赖时却不一定用到。

总的来说，关联和依赖是同级的；组合是一种聚合，而聚合是一种关联；引用则是相对独立的。

与此相关的文章有：

1) 《UML用户指南》第10章，Booch+详细讲述了依赖和关联的含义和区别。

2) 《设计模式》中文版第15~16页，Gof讲述了聚合和相识的差别。

3) 《非程序员》第二期之《类之间设置成“关联”OR“依赖”似乎全在个人喜好》是几位朋友就聚合、关联和依赖的区别进行的很好的讨论。

至此，如果您对它们的定义持不同意见，又或者觉得难以理解的话，不妨把别人的那一套都抛开，自己把它们重定义一遍。反正我们又不是理论家，就算定义得不科学也没关系，只要和我们的项目有关的人员都一致的理解和接受就可以了。毕竟有效的沟通才是我们真正的目的。

---

实践建议

按需剪裁。项目要用到什么就学习什么，暂时不用的就放下。我们的目的是当前的系统建模，而不是一下子成为UML高手。

自由扩展。结合我们的实际情况，在使用的过程中，要明确UML的重点是“沟通”，其次才是“公共”。UML本身有许多规则和约定，但没必要一一遵守。只要有利于沟通的，我们就采用，否则就摒弃。通常我们的文档只是在小范围里传播，要统一理解并不困难。当然，当规则定好了后，最好就不要随意更改了。