【UML】初识UML（二）
UML带来了什么
在上一篇文章中我们了解了面向过程和面向对象两种不同方法在描述现实世界的不同，相信面向对象是更好的方法。但是，面向对象也有着天然的困难，这篇博客我们来看看面向对象设计的事实标准UML是如何解决这些困难的。
什么是UML
面向对象的兴起是从编程领域开始的。最初，人们只是为了改进开发效率，编写更容易管理、能够重用的代码，在编程语言中加入了封装、继承、多态等概念，以求得代码的优化。但分析和设计仍然是一结构化的面向过程方法为主。
但是呢，在实践中，人们很快就发现了问题：编程需要的对象不但不能够从设计中自然而然的推导出来，而且强调连续性和过程化的结构化设计与事件驱动型的离散对象结构之间有着难以调和的矛盾。由于设计无法自然推导出对象结构，使得对象结构到底代表了什么样的含义变得模糊不清；同时，设计如何指导编程，也成为了困扰在人们心中的一大疑问。
为了解决这些问题，一批面向对象的设计方法（OOD方法）开始出现。虽然OOD方法的出现解决了从设计到开发的困难，随着应用程序的进一步复杂，需求分析成为比设计更为重要的问题，于是OOA（面向对象分析）方法开始走上了舞台，其中最重要的方法便是UML的前身，即：由Booch创造的Booch方法，由Jacobson创造的OOSE、Martin/Odell方法和Rumbaugh创造的OMT、Shlaer/Mellor方法。这些方法虽然各不相同，但它们的共同的理念却是非常相似的，于是三位面向对象大师决定将他们自己的方法统一起来，UML出现了。
统一语言
统一的意义似乎不用多说，秦始皇历史上的一大功绩便是统一语言和度量衡。目前，随着软件工程的不断成熟，软件开发越来越朝着专业化和横向分工化发展。以前人们认为从需求到代码是一个紧密联系的过程，是不可分离的。一旦分开就会导致高成本和高技术风险。然和与现代工业的分工越来越细致和专业化的趋势一样，软件行业的需求、分析、设计、开发这些过程也被分离开来并专业化了。
软件开发工作中这种将角色细分，将职责明确的做法，在提高专业化和资源效率的同时也带来了严重的沟通问题。文档从一个角色传向另一个角色，从一个组织传向另一个组织的过程中如何保证信息被准确地传达和准确地理解呢？一种好的办法就是大家都使用统一的或者说标准化的语言。UML统一建模语言的意义也正是在于此，他试图用统一的语言来覆盖整个软件过程，让不同的团队操着同一个口音顺畅地交流。
统一语言的另一个意义是要让人和机器都能读懂。
好，统一的任务完成了，接下来的任务就是可读性。如果语言可读性很差，人们在理解起来同样会很有困难。一门好的语言要能够让人们快速理解并留下深刻印象。
我们知道，相对文字和图形，人脑对图形的接受能力显然更强。因此，UML采用了“可视化”的图形方式来定义语言。
可视化
在这里可视化的含义并不是指UML的图形是可以用眼睛看到的，可视化的含义是指，UML通过它的元模型和表示方法，把那些通过文字或其他表达方法很难表达清楚地，隐晦的潜台词用简单直观的图形表达和暴露出来，准确而直观地描述复杂的含义。把“隐晦的”变成“可视”的，也就是把文字变成图形，这才是UML可视化的真正含义。
举个例子，有一段文字描述：造一辆车身是红色金属漆的小轿车，装备四个普利司通牌的轮胎，它是一辆四门车，车门是加厚的，并且前后门玻璃上贴黑色的膜。前后挡风玻璃都装有电热丝，后视镜是电动可调的。
这段话看上去很简单，谁都可以一下子看明白，因为汽车是我们很熟悉的事务。但是如果一个没有看到过汽车的人要靠这段话去真正造一辆汽车一定会觉得很多地方没有讲清楚。所以我们试着换一种形式来表达。
显然上图的描述所表达出来的含义远远超出了文字所描述的内容。事实上，实际项目中由于表达和理解之间的歧义导致的返工绝不在少数。图形的优势就在这里。
UML统一了语言，让隐晦的含义可视化了。接下来，这种统一的可视化语言又如何来描绘现实世界并解决面向对象的困难呢？
如何解决面向对象的问题
针对上一篇文章中提到的面向对象的问题，我们该如何解决呢？
- 一种把现实世界映射到对象世界的方法。→将现实世界转化为业务模型
- 一种用对象世界描述现实世界的方法。→将业务模型转化为概念模型
- 一种验证对象世界行为正确反映了现实世界的方法。→将概念模型转化到设计模型
写在后面
写到这里，相信我们对UML有了一个初步的认识，如果你看完之后会有一种拍案而起，大呼“啊哦，原来UML是这么回事”，我会非常高兴。
在这里，推荐大家一本关于学习UML非常好的书籍《大象》。
更多精彩UML内容，请点击：