面向对象的精髓在抽象；面向对象的困难在抽象；面向对象的成功在于成功的抽象；面向对象的失败在于失败的抽象。
对象提供了一种处理复杂性问题的方式。
抽象层次；
面向对象的困难：
1）对象是怎么被抽象出来的？现实世界和对象世界看上去差别那么大，为什么要这么抽象而不是那么抽象呢？（Why）
2）对象世界在于其灵活性，可以任意组合，可是我们怎么知道某个组合就正好满足了现实世界的需求呢？什么样的组合是好的？什么样的组合是差的呢？（How）
3）抛开现实世界，对象世界是如此的难以理解。如果只给我一个对象组合，我怎么才能理解它表达了怎样的含义呢？（What）
实际工作中，我们常常设计出许多类来满足某个需求。但是如果问一问为什么要这样设计，为什么是五个类而不是七个类？为什么是十个方法而不是十二个？能很好回答这个问题的人不多，绝大部分人的回答是凭检验。经验是宝贵的，可惜经验也是靠不住的，凭经验的另一个说法是拍脑袋。从需求到设计，从现实到对象，那些类的确如孙悟空从石头里蹦出来一样，设计师一拍脑袋就出来了。
造成以上问题的原因是因为现实世界和对象世界之间存在着一道鸿沟，这道鸿沟的名字叫做抽象。要想跨越这道鸿沟，我们需要：
1）一种把现实世界映射到对象世界的方法
2）一种从对象世界描述现实世界的方法
3）一种验证对象世界行为是否正确反映了现实世界的方法
UML背后所代表的面向对象分析设计方法，正好架起了跨越这道鸿沟的桥梁。
如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业务流程图，然后顺藤摸瓜，找出业务流程中每个步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给下一个环节的。那么很不幸，你还在做面向过程的事情。
如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代码表，问他们类似的问题：你平时做什么？这件事是谁交代的？做完了你需要通知或传导给谁吗？做这件事情你都需要填写什么表格吗？那么恭喜你，你已经OO啦。
从现实世界到业务模型：建立模型是指通过对客观事物建立一种抽象的方法，用来表征事物并获得对事物本身的理解，再把这种理解概念化，并将这些逻辑概念组织起来，形成对所观察的对象的内部结构和工作原理的便于理解的表达。模型要能够真实反映客观事物就需要有一个论证过程，使得模型建立过程是严谨的，并且结果是可追溯和可验证的。
现实世界无论多么复杂，其本质无非是由人、事、物和规则组成的。人驱动系统，事体现过程，物记录结果，规则是控制。建立模型的关键是弄明白有什么人，什么人做什么事，什么事产生什么物，中间有什么规则，再把人、事、物之间的关系定义出来，一个模型基本就成型了。
UML采用称为参与者（actor）的元模型作为信息来源提供者，参与者代表了现实世界的“人”。UML采用称为用例（use case）的一种元模型来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。这个业务目标就是现实世界中的“事”。而这件事是怎么做的，依据什么规则，则通过称为业务场景（business scenario）和用例场景（use case scenario）的UML视图来描绘的，这些场景就是现实世界中的“规则”。最后，UML通过称之为业务对象模型（business object model）的视图来说明在达成这些业务目标的过程中涉及到的事物。业务对象模型则代表了现实世界中“物”。
从业务模型到概念模型：UML通过称为概念化的过程来建立适合计算机理解和实现的模型，这个模型称为分析模型。分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型主要的元模型有：
边界类（boundary）：广义上说，任何一件事物都分为里面和外面，边界决定了外面能对里面做什么“事”。
实体类（entity）：实体类可看做是业务实体的实例化结果。
控制类（control）：边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML观点来看，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能直接相互访问，他们需要通过控制类来代理访问要求。
从概念模型到设计模型：概念模型就是绘制汽车需要的所有零部件，并且绘制出如何组装这些零部件的步骤。设计模型的工作就是建造零部件，组装汽车的过程。大多数情况，实现类可简单的从分析类映射而来。在设计模型中，概念模型中的边界类可被转化为操作界面或系统接口；控制类可被转化为计算程序或控制程序，例如工作流，算法题等；实体类可转化为数据库表、XML文档或其他带有持久性特征的类。
