只有掌握了软件过程，才会知道为什么要有用例，为什么要有分析模型；站在软件过程的立场，那些孤独的UML视图才会变得有生命力，才会知道在什么时候，在什么地方需要用什么样的UML图符来表达软件的观点，也才会知道UML的那些视图到底在软件开发过程里起到他什么作用。
统一过程学习的困难在于庞大和复杂，而UML学习的困难在于不知如何使用。
2 建模基础
建模（Modeling），是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达
第一个问题“怎么建”，依赖于方法论，再上升一点到哲学高度就是认识论。
做需求的时候，首要目标不是要弄清楚业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么？参与者的目标就是你的抽象角度。与分析一个复杂的业务流程相比，单独分析参与者的一个个目的要简单得多。实际上，这就是用例！这也就是为什么用例会成为业务建模的方法的原因之一。
第二个问题“模是什么”，则依赖于确定了抽象角度下的场影模拟。
2.2用例驱动
- 逻辑视图
- 进程视图
- 部署视图
- 实施视图
2.3抽象层次
在软件开发过程中，主体上应当彩自顶向下的方法，用少量的概念覆盖系统需求，再逐步降低抽象层次，直到代码编写。同时应当辅以自底向上的方法，通过总结在较低抽象层次的实践经验来改进较高层次的概念以提升软件质量。
2.4视图
需要搞明白的两个问题
- 应该为哪能些软件信息绘制哪些视图？
- 应该给哪能些干系人展示哪些视角？
2.5对象分析方法
- 一切都是对象
- 对象都是独立的
- 对象都具有原子性
- 对象都是可抽象的
- 对象都有层次性
