一直以来想找一本书来帮助我学习UML这一先进工具（不知道这样说对不到），苦于不得法，书看不少，但不得要令，有的书看得没发看下去。这几天有幸看到《大象Thinking in uml》这本书。初看一下，两个字：好书！
第一部分 准备篇--需要了解
1、为什么需要UML
面向对象方法（我个人很喜欢作者对面向对象的描述），是将世界看作一个个相互独立的对象，相互之间并无因果关系，只有在某个外部力量的驱动下，对象之间才会依据某种规律相互传递信息。从微观角度说，这些独立的对象有着一系列奇妙的的特性。例如，对象有着坚硬的外壳，从外部看来除了它用来与外界交互的消息通道之外，对象内部就是一个黑匣子，什么也看不到，这被称为封装；再例如对象可以结合在一起形成新的对象，结合后的对象具有前两者特性的总和，这称为聚合；对象可以繁育，产下的孩子将拥有父辈全部的本领，这称为继承；对象都是多面派，它会根据不同的要求展现其中的一个面，这就是接口；多个对象可能长着相同的脸，而这张脸背后却有着不同的行为，这就是多态。从宏观角度说，对象是“短视”的，它不知道它身处的整个世界是怎么回事，也不知道它的行为是如何贡献给这个世界的。它只知道与它有着联系的身边的一小群伙伴（这称为依赖），并与伙伴间保持着信息交流的关系（这称为耦合）。同时对象也是“自私”的，即便在伙伴之间，每个对象也仍然顽固地保持着自己的领地，只允许其它人通过它打开的小小窗口（这称为方法）进行交流，从不会向对方敞开心扉。
抽象层次，好处是不论在哪一个层次上，我们都只需要面对有限的复杂度和有限的对象结构，从面可以专心地了解这个层次上的对象是如何工作的；抽象层次的另一个更重要的好处是低层次的零件更换不会影响高层次的功能。
面向对象的困难（说真的，这也是我想搞明白的东西，因为如此所以没学成，当然，不排除智商因素）
- 对象是怎么被抽象出来的？现实世界和对象世界看上去差别是那么大，为什么要这么抽象而不是那么抽象呢？（Why)
- 对象世界由于其灵活性，可以任意组合，可是我们怎么知道某个组合就正好满足了现实世界的需求呢？什么样的组合是好的，什么样的组合是差的呢？（How）
- 抛开现实世界，对象世界是如此的难以理解。如果只给我一个对象组合，我怎么才能理解它表达了怎么样的含义呢？（What)
抽象是面向对象的精髓所在，同是也是面向对象的困难所在。我们需要：
- 一种把现实世界映射到对象世界的方法。
- 一种从对象世界描述现实世界的方法。
- 一种验证对象世界行为是否正确反映了现实世界的方法。
建立模型是指通过客观事物建立一种抽象的方法，用来表片事物并获得对事物本身的理解，再把这种理解概念化，并将这些逻辑概念组织起来，形成对所观察的对象的内部结构和工作原理的便于理解的表达。
抽象过程：从现实世界到业务模型，从业务模型到概念模型，从概念模型到设计模型
绘制分析模型最主要的无模型有：
- 边界类（boundary)。边界是面向对角分析的一个非常重要的观点。狭义上说，边界就是大家的界面，所有对计算机的操作都要通过界面进行。从广义地说，任何一件事物都分为里面和外面，外面的事物和里面的事物之间的任何交互都需要有一个边界。换句话说，边界决定了外面能对里面做什么“事”。
- 实体类（entity)。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。
- 控制类（control)。边界和实例都是静态的，本身并不会动作。UML采用控制类来表述需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不够直接相互访问，它们需要通过控制类来代理访问要求。
RUP（Rational Unified Process）译为统一过程。是一个采用了面向对象思想，使用UML作为软件分析设计语言，并且结合了项目管理、质量保证等许多软件工程知识给综合而成的一个非常完整和庞大的软件方法。它归纳和集成了软件开发活动中的最佳实践，它定义了软件开发过程中最重要的阶段和工作（四个阶段和九个核心工作流），定义了参与软件开发过程的各种角色和他们的职责，还定义了软件生产过程中产生的工件（见注），并提供了模板。最后，采用演进式软件生命周期（迭代）将工作、角色和成果物串在一起，形成了统一过程。
