参考：Process-oriented vs. Object-oriented
前言
软件行业在采用OO的思想后，从一开始只对编码使用OO，到现在“分析-设计-编码”全部环节使用OO，形成了OOA、OOD、OOP。作为Programmer，只知道根据设计编码，但是设计如何指导编码，设计又是怎么开来的却不十分清楚。本文试着粗略概括现实世界如何层层抽象到对象世界。
理解现实世界
这里说的现实世界，是以“人”为出发点理解的现实世界。软件的目的是服务于“人”，自己简单写的Hello World程序基本上算不上什么软件，除了向你演示如何使用一门语言外没啥作用。如果我们站在很高的抽象层次，以高度归纳的视角来看这个世界的运作，就会发现现实世界无论多复杂，无论是哪个行业，无论做什么业务，其本质无非是由人、事、物和规则组成的。人是一切的中心，人要做事，做事就会使用一些物并产生另一些物，同时做事需要遵循一定的规则。
在计算机没发明出来前，这个世界也是由人、事、物和规则组成的，没有计算机人类一样活得很好。计算机发明后，有了软件，软件解放了人类部分工作，即帮助人类完成了“事”。软件开发就是以“人”为出发点，设计出满足“人”特定期望的东西。在实现“事”的过程中会依据“规则”使用某些“物”。
现实世界到抽象世界
捕获现实世界需求
软件为人服务，设计软件的第一步便是准确捕获现实世界。现实世界也就是软件建模中的领域问题，一个领域问题极其庞大，我们该如何选取角度建立模型呢？领域问题就好比一座城市，城市各个角落遍布摄像机。想要了解一座城市，只需要根据你所关心的问题选择合适的机位即可。这里面的关键是如何选取领域问题的观察角度，而选取观察角度的关键是人，人所关心的观察角度才是有意义的角度，人不关心的角度呈现给人也没啥乱用。
回到软件设计上来，客户的需求既是我们面临的问题领域，用户关心的才是我们正确的建模方向。UML中使用用例来准确捕获客户的原始需求，即上图现实世界——业务模型这一环节。当然原始需求不是那么容易捕获的，客户不懂计算机，甚至连他想要实现的业务目标都可能描述不清楚，这需要反复的沟通、甄别、确认。
业务模型——概念模型
现实世界被业务模型映射并且记录下来，但这只是原始需求信息，距离可执行的代码还很遥远，必须把这些内容再换成一种可以指导开发的表达方式。UML通过称之为概念化的过程（Conceptual）来建立适合计算机理解和实现的模型，这个模型称为分析模型（Analysis Model）。分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求；同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。
分析模型主要采用的元模型有：
边界类（boundary）。边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。只要是两个不同职责的簇之间的交互都需要有一个边界，换句话说，边界决定了外面能对里面做什么“事”。
实体类（entity）。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。
控制类（control）。边界和实体都是静态的，本身并不会动作。UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从UML的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。
概念模型——设计模型
我理解这个阶段就是UML中的类图。在大多数情况下，实现类可以简单地从分析类映射而来。在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XML文档或者其他带有持久化特征的类。