1、建模
建模的定义本身就和建模工作一眼非常抽象和难以理解。简单地说：建模包含两个问题，一个是怎么建？另一个，“模”是什么？
做需求的时候，首要目标不是弄清楚业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么？参与者的目标就是你的抽象角度。与分析一个复杂的业务流程相比，单独分析参与者的一个个目的要简单得多。实际上，这就是用例！这也就是为什么用例会成为业务建模的方法的原因之一。
第二个问题“模是什么”，则依赖于确定了抽象角度下的场景模拟。
一旦决定了抽象角度，就确定了一个目标。一个由抽象角度确定了的目标，需要由静态的事物加上特定条件下产生的一个特定的场景来完成，即静态的事物（物）+特定的动作（参与者的驱动）=特定的场景（事物）。模就是人、事、物、规则。建模公式：
- 问题领域=∑抽象角度
- 抽象角度=问题领域边界之外的参与者的业务目标=业务用例
- 业务用例=∑特定场景
- 特定场景=静态的事物+特定的条件+特定的动作
- 特定的事=特定的事物+特定的规则+特定的人的行为
2、用例驱动
要解决问题领域就要归纳出所有必要的抽象角度（用例），所以我们找到那些事物、规则和行为实现了所有必要的用例，那么问题领域就被解决了。
在实际的软件项目中，一个软件要实现的功能通过用例来描述，接小赖的所有分析、设计、实现、测试都由用例来驱动，即以实现用例为目标。
用例可以驱动的内容包括：
逻辑视图：以图形的方式说明关键的用例实现、子系统、包和类，它们包含在架构方面具有重要意义的行为，即建模公式中的那些人、事、物、规则是如何分类组织的。
进程视图：以图形方式说明了系统中进程的详细组织结构，其中包括类和子系统到进程和线程的映射，即建模公式中的那些人、事、物、规则事如何交互的，它们的关系如何。
部署视图：以图形方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布，即建模公式中的那些人、事、物、规则是如何部署在物理节点上的。
3、抽象层次
抽象层次是面向对象方法中极其重要的，但是又非常难以掌握的技巧。学会站在不同的抽象层次考虑问题是建立好模型的基础。
抽象层次越高，具体信息越少，但是概括能力越强；反之，具体信息越丰富，结果越确定，但相应的概括能力越弱。从信息的表达能力上，抽象层次越高表达能力越丰富，越容易理解。
但随之而来的另一个问题是如果抽象层次太高，信息量过少的话，实施起来又会产生新的困难——信息量不足。
抽象有两种方法：自顶向下、自底向上。自顶向下的方法适用于让人们从头开始认识一个事物，自底向上的方法适用于在实践中改进和提高认识。
在软件开发过程中，主体上应当采用自顶向下的方法，用少量的概念覆盖系统需求，再逐步降低抽象层次，直到代码编写。同时应当辅以自底向上的方法，通过总结在较低抽象层次的实践经验，来改进较高层次的概念以提升软件质量。
一般的抽象层次：业务建模、概念建模、系统建模、设计实现。
与抽象层次相关的另一个问题是边界，实际上抽象层次与边界的选择总是相生相伴的。
4、对象分析方法
- 一切都是对象
- 对象都是独立的：对象与对象之间是天然独立的，只是在某个特定的场景下，它们的某一个特定的实例才相互联系在一起。要深入了解对象，需要分析很多个该对象的实力所参与的场景，通过归纳整理抽象出对象的一般特性。对象的独立性带来的正是对象的可抽象能力和可扩展能力。
- 对象都具有原子性：无论什么时候，在分析过程中都应当将对象视为一个不可分割的原子，哪怕这个对象规模很大。对象总有一个边界，永远也不应该打破边界去窥探对象的内部。应当将分析过程中，得到的所有对于对象的认识，附加在对象边界上，在实现这个对象之前，不理会其内部的细节。这称为面向接口编程。
- 对象都是可抽象的：在分析过程中，得到的任何一个对象都有特定的方面可作为抽象。对象所参与的场景越多，对象越有抽象价值。那些参与了很多场景的对象，它们是分析设计中重点以及成败关键。
- 对象都有层次性：对象是有着抽象层次的。层次越高，其描述越粗略但适应能力越广；层次越低则描述越精确但适应能力越下降。在分析过程中，应当根据问题领域的复杂程度设定多个抽象层次，在每个层次上使用适合的抽象程度的对象描述。有助于减少分析的难度和工作量。