面向过程&面向对象
面向过程和面向对象其实都是一种软件技术，我们一般把面向过程归纳为结构化分析方法，常使用DFD图、ER模型、UC矩阵等，把面向对象则归纳为继承、封装、多态等具体技术，事实上，所有的技术都只是人们采用不同方法来认识和描述这个世界时所采用的工具。
我们引用Booch的话：
我对面向对象编程的目标从来都不是复用，相反，对我来说，对象提供了一种处理复杂性问题的方式，这个问题可以追溯到亚里士多德：你把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，如结构化设计方法。然而，系统已经达到了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统---我认为，这才是面向对象编程运动的真正的胜利。
归纳起来，面向对象这种认识论能够帮助我们构建更为复杂的系统来解释越来越复杂的现实世界。
面向对象，认为这个世界的本质是由对象构成的，一切皆为对象，平时看上去相互无关的对象在不同的驱动力和规则下体现不同的运动过程，然后这些过程便展现了我们这个生动的世界。
面向过程，认为世界的一切都不是孤立的，它们互相紧密地联系在一起，缺一不可，互相影响，互相作用，形成一个个具有严格因果关系的小系统，更多小系统组成大系统，所有小系统之间的联系也是紧密和不可分割的。
把世界视为过程这个方法本身有一个假设前提，即这个过程是稳定的，这样我们才有分析的基础，所有的工作成果都依赖于这个过程。过程中的各个环节有着严格的因果关系。很可惜，这个世界不是一成不变的，无时无刻在发生着变化，所以系统所依赖的因果关系变得越来越脆弱。面向过程面临了太多的困难。已经很难应付世界的复杂性和频繁变革了。
其实并非面向过程的方法不正确，而是因为构成一个系统的因素太多了，要把所有可能的因素都考虑到，把所有的因果关系都分析清楚，再把这个过程模拟出来实在是太困难了，我们的精力有限，计算能力有限，所以面向过程对这个复杂的世界已经显得无能为力了。
"拥有一把锤子未必能成为建筑师",了解面向对象语言是必要的,但不是首要的,了解对象思想才是关键.
面向对象(Object Oriented)方法把世界看作一个一个相互独立的对象，相互之间并无因果关系，它们之间是“鸡犬之声相闻，老死不相往来”的。只有在某个外部力量的驱使下，对象之间才会依据某种规律相互传递信息，这些交互构成了现实世界的一个“过程”，在没有外力的作用下，对象则保持“静止”状态。
面向对象有一个非常重要的特性：抽象层次。如：汽车。不论在哪一个抽象层次，我们都只要面对有限的复杂度和有限的对象结构，可以专心了解这个层次上的对象是如何工作的。另外，低抽象层次的零件更换不会影响高层次的功能。如汽车的火花塞。
但是面向对象也有面向对象的问题：
对象是怎么被抽象出来的？
对象可以任意组合，到底怎样组合才是好的？
同一个问题可能有多个设计，怎样的设计是好的？
实际工作中，常常设计多个类来满足需求，但是请问为什么要这样设计？为什么是3个类而不失5个？为什么是7个方法而不是10个方法？能回答这个问题的人不多，大多数都是凭经验，从需求到设计，从实现到对象，设计师都是一拍脑袋就出来了，凭经验，说不出个一二三来，初学者就更懵了，只能先弄几个类出来，看能不能满足需求，不行了再修改，不断地尝试中。
由需求怎样分析、推导出设计，而设计出的成果怎样验证是否满足了需求。很多有经验的设计师都很难说出一个合理的推导过程。
现实世界和对象世界存在一道鸿沟---这道鸿沟叫做抽象，抽象是面向对象的精髓。也是困难点，OO设计大师和菜鸟的差别很大程度就区别在抽象能力上。
很幸运，大师级的前辈们发明了UML和UML背后的OOAD方法，正好架起了跨越这道鸿沟的桥梁。
在OO开发中,至关重要的能力是熟练地为软件对象分配职责.OOAD中还有其它重要的技能,但强调职责分配是一项既难以掌握又至关重要的技能.
UML是什么
UML是标准的图形表示法,如何用对象进行思考很关键.UML不是OOAD,也不是方法,只是图形表示法,如果没有真正掌握如何创建优秀的面向对象设计,如何评估和改进设计,学习UML或CASE工具毫无意义,对象思想才是重点和难点.
什么是分析和设计
分析:强调的是对问题和需求的调查研究.
设计:强调的是满足需求的概念上的解决方案,而不是实现.
面向对象分析(OOA):强调的是在问题领域内发现和描述对象(或概念).
面向对象设计(OOD):强调的是定义软件对象以及它们如何协作以实现需求.
UML和UP
UML背景
OO编程语言在上世纪60-70年代崭露头角(Smalltalk/Simula),在82年后,到91,92,逐步开始发展对象思想.不乏一些大师级的人物,如Kent Beck,Ivar Jacobson(UML创立者之一),Jim Rumbaugh(UML创立者之一)
UML始于94年,它结合了Booch和OMT方法,当时被称为统一方法. Booch,Rumbaugh,Ivar Jacobson 加入了Rational,97年形成了UML1.0
谈到UML，不能不谈RUP，UML和RUP师出同门。
什么是UP
UP(Unified Process)已经成为一种流行的构造面向对象系统的迭代软件开发过程.特别是RUP(Rational Unified Process),是对统一过程的详细精化,并已广泛采纳.
UP阶段（4个阶段）:
初始阶段:大体上的构想、业务案例、范围和模糊评估。
细化阶段:已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求和范围，以及更实际的评估。
构造阶段:对遗留下的风险较低和比较简单的元素进行迭代实现，准备部署。
移交阶段:进行beta测试和部署。
初始阶段不是需求阶段，而是研究可行性的阶段。在此阶段要进行充分的调查以确定继续还是终止项目。
细化阶段也不是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题的阶段。
图：
UP科目（9个核心工作流）：
业务建模
需求
设计
实现：编程和构建系统
测试
部署
配置和变更管理
项目管理
环境：建立工具和过程环境
关于UML中的不同视图的使用，不是全部都要，关键是想从哪个角度描述事物，站在软件工程的角度，需要什么工具，才使用相应的工具来描述。
面向过程和面向对象其实都是一种软件技术，我们一般把面向过程归纳为结构化分析方法，常使用DFD图、ER模型、UC矩阵等，把面向对象则归纳为继承、封装、多态等具体技术，事实上，所有的技术都只是人们采用不同方法来认识和描述这个世界时所采用的工具。
我们引用Booch的话：
我对面向对象编程的目标从来都不是复用，相反，对我来说，对象提供了一种处理复杂性问题的方式，这个问题可以追溯到亚里士多德：你把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，如结构化设计方法。然而，系统已经达到了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统---我认为，这才是面向对象编程运动的真正的胜利。
归纳起来，面向对象这种认识论能够帮助我们构建更为复杂的系统来解释越来越复杂的现实世界。
面向对象，认为这个世界的本质是由对象构成的，一切皆为对象，平时看上去相互无关的对象在不同的驱动力和规则下体现不同的运动过程，然后这些过程便展现了我们这个生动的世界。
面向过程，认为世界的一切都不是孤立的，它们互相紧密地联系在一起，缺一不可，互相影响，互相作用，形成一个个具有严格因果关系的小系统，更多小系统组成大系统，所有小系统之间的联系也是紧密和不可分割的。
把世界视为过程这个方法本身有一个假设前提，即这个过程是稳定的，这样我们才有分析的基础，所有的工作成果都依赖于这个过程。过程中的各个环节有着严格的因果关系。很可惜，这个世界不是一成不变的，无时无刻在发生着变化，所以系统所依赖的因果关系变得越来越脆弱。面向过程面临了太多的困难。已经很难应付世界的复杂性和频繁变革了。
其实并非面向过程的方法不正确，而是因为构成一个系统的因素太多了，要把所有可能的因素都考虑到，把所有的因果关系都分析清楚，再把这个过程模拟出来实在是太困难了，我们的精力有限，计算能力有限，所以面向过程对这个复杂的世界已经显得无能为力了。
"拥有一把锤子未必能成为建筑师",了解面向对象语言是必要的,但不是首要的,了解对象思想才是关键.
面向对象(Object Oriented)方法把世界看作一个一个相互独立的对象，相互之间并无因果关系，它们之间是“鸡犬之声相闻，老死不相往来”的。只有在某个外部力量的驱使下，对象之间才会依据某种规律相互传递信息，这些交互构成了现实世界的一个“过程”，在没有外力的作用下，对象则保持“静止”状态。
面向对象有一个非常重要的特性：抽象层次。如：汽车。不论在哪一个抽象层次，我们都只要面对有限的复杂度和有限的对象结构，可以专心了解这个层次上的对象是如何工作的。另外，低抽象层次的零件更换不会影响高层次的功能。如汽车的火花塞。
但是面向对象也有面向对象的问题：
对象是怎么被抽象出来的？
对象可以任意组合，到底怎样组合才是好的？
同一个问题可能有多个设计，怎样的设计是好的？
实际工作中，常常设计多个类来满足需求，但是请问为什么要这样设计？为什么是3个类而不失5个？为什么是7个方法而不是10个方法？能回答这个问题的人不多，大多数都是凭经验，从需求到设计，从实现到对象，设计师都是一拍脑袋就出来了，凭经验，说不出个一二三来，初学者就更懵了，只能先弄几个类出来，看能不能满足需求，不行了再修改，不断地尝试中。
由需求怎样分析、推导出设计，而设计出的成果怎样验证是否满足了需求。很多有经验的设计师都很难说出一个合理的推导过程。
现实世界和对象世界存在一道鸿沟---这道鸿沟叫做抽象，抽象是面向对象的精髓。也是困难点，OO设计大师和菜鸟的差别很大程度就区别在抽象能力上。
很幸运，大师级的前辈们发明了UML和UML背后的OOAD方法，正好架起了跨越这道鸿沟的桥梁。
在OO开发中,至关重要的能力是熟练地为软件对象分配职责.OOAD中还有其它重要的技能,但强调职责分配是一项既难以掌握又至关重要的技能.
UML是什么
UML是标准的图形表示法,如何用对象进行思考很关键.UML不是OOAD,也不是方法,只是图形表示法,如果没有真正掌握如何创建优秀的面向对象设计,如何评估和改进设计,学习UML或CASE工具毫无意义,对象思想才是重点和难点.
什么是分析和设计
分析:强调的是对问题和需求的调查研究.
设计:强调的是满足需求的概念上的解决方案,而不是实现.
面向对象分析(OOA):强调的是在问题领域内发现和描述对象(或概念).
面向对象设计(OOD):强调的是定义软件对象以及它们如何协作以实现需求.
UML和UP
UML背景
OO编程语言在上世纪60-70年代崭露头角(Smalltalk/Simula),在82年后,到91,92,逐步开始发展对象思想.不乏一些大师级的人物,如Kent Beck,Ivar Jacobson(UML创立者之一),Jim Rumbaugh(UML创立者之一)
UML始于94年,它结合了Booch和OMT方法,当时被称为统一方法. Booch,Rumbaugh,Ivar Jacobson 加入了Rational,97年形成了UML1.0
谈到UML，不能不谈RUP，UML和RUP师出同门。
什么是UP
UP(Unified Process)已经成为一种流行的构造面向对象系统的迭代软件开发过程.特别是RUP(Rational Unified Process),是对统一过程的详细精化,并已广泛采纳.
UP阶段（4个阶段）:
初始阶段:大体上的构想、业务案例、范围和模糊评估。
细化阶段:已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求和范围，以及更实际的评估。
构造阶段:对遗留下的风险较低和比较简单的元素进行迭代实现，准备部署。
移交阶段:进行beta测试和部署。
初始阶段不是需求阶段，而是研究可行性的阶段。在此阶段要进行充分的调查以确定继续还是终止项目。
细化阶段也不是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题的阶段。
图：
UP科目（9个核心工作流）：
业务建模
需求
设计
实现：编程和构建系统
测试
部署
配置和变更管理
项目管理
环境：建立工具和过程环境
关于UML中的不同视图的使用，不是全部都要，关键是想从哪个角度描述事物，站在软件工程的角度，需要什么工具，才使用相应的工具来描述。
