以前一提到UML，就想到了复杂的流程图。很敬佩哪些想想就能画出整个系统的UML图的人，因为他们头脑中有整个软件架构的蓝图，这样在编写实现的时候，就会知道哪个地方改怎么做，哪个地方如何扩展。

　　而想成为架构师，UML也是必备的技能。这里就根据《大象——Thinking in UML》总结一些学习笔记。

　　平时总是在说什么是面向对象，什么是面向过程。

　　面向过程，就是典型的C语言这种，一个main函数，从头走到脚，中间可能涉及到一些方法的调用，但是整个代码完全是流水线一样。这样就会导致一个问题，虽然代码流程很清晰，但是不容易扩展，我需要修改某一个计算过程，有可能导致全部代码需要重写。

　　而面向对象，就是以一种对象的角度来编写程序，设计程序，每个对象具有自己的生命特征。每个对象内部具有一些复杂的变量以及方法，对外提供接口或者公共方法进行调用，这就是封装。而对象之间可以互相关的继承，借鉴存在的方法，这就是继承。相同类型的对象，可以提取公共的部分，形成一个新的父类对象，这就是抽象。每个相同类型的子对象之间可能存在不同的方法，这就是多态。

　　这样，通过对象的方式，来看待世界，整个过程就变得解耦了，一旦需要扩展或者修改某个地方，单纯的修改与之对应的对象就可以了。

　　而这其中的难点，就是如何从现实世界中的业务场景转换到抽象的对象模型；而通过复杂对象模型如何表示业务场景。

　　通过上面这个步骤，就可以从现实世界抽象出模型来表示业务场景了。

　　首先通过建模，把现实世界中需要的一些数据进行建模，建立对应的模型。

　　然后根据这些模型去设计相关的一些概念，比如控制类，实体类，以及边界的展现类。

　　最后设计这些概念模型，进行代码级的实现。

　　设计思想有了，那么就出现了一种叫做RUP的统一建模的过程模式，通过这种建模的模式，可以完整而且稳定的展示一个软件的软件生命周期。

　　通过这四个阶段，9个核心，完美的诠释了传统软件的生命活动，但是现代的软件开发，大多讲究极限编程，敏捷开发，想要通过快速的迭代更新，来进行快速的适应，以满足快速的需求变化。但是对于一些10年之久的系统来说，稳定才是最重要的，因此这种统一过程往往是最佳的选择。

　　对于UML来说，我们最难的就是如何建模了！

　　首先要明确，建模的目的是什么？需要满足什么业务场景！其次，根据多种场景抽象出模型。

　　传统的方式可以通过自顶向下，或者自底向上的方式来进行。

　　自底向上，就是首先建立底层小对象的模型，再通过组合等方式，拼凑出完整的业务场景。

　　自顶向下，就是先进行大体的场景描述，再慢慢的细分功能。

　　一般都是这两种方式，不断的迭代，最终找到合适的方案。

【UML】——为什么要使用UML