0：基本概念
面向对象方法包括：面向对象分析，面向对象设计，面向对象程序设计
一：统一建模语言（UML）
1：UML结构
UML结构包括UML的基本构造块，支配这些构造块如何放在一起的规则（架构）和一些运用于整个UML的机制
（1）构造块：
事物：
UML中的事物也称为建模元素，包括结构事物（structural things）、行为事物（behavioral things，动作事物）、分组事物（grouping things）和注释事物（annotational things，注解事物）。这些事物是UML模型中最基本的面向对象的构造块。
关系：
UML 用关系把事物结合在一起，UML中的关系主要有四种：
（1）依赖（dependencies）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
（2）关联（association）：一种描述一组对象之间连接的结构关系，如聚合关系(描述了整体和部分间的结构关系)。
（3）泛化（generalization）：一种一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
（4）实现（realization）：类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
图：
UML 2.0包括14种图，分别列举如下：
（1）类图（class diagram）：描述一组类、接口、协作和它们之间的关系。在面向对象系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
（2）对象图（object diagram）：描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出了系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
（3）构件图（component diagram）：描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。
（4）组合结构图（composite structure diagram）：描述结构化类（例如构件或类）的内部结构，包括结构化类与系统其余部分的交互点。它显示联合执行包含结构化类的行为的构件配置。组合结构图用于画出结构化类的内部内容。
（5）用例图（use case diagram）：描述一组用例、参与者（一种特殊的类）及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。
（6）顺序图（sequence diagram，序列图）：是一种交互图（interaction diagram），交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
（7）通信图（communication diagram）：也是一种交互图，它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念，但每种图所强调的概念不同，顺序图强调的是时序，通信图则强调消息流经的数据结构。
（8）定时图（timing diagram，计时图）：也是一种交互图，它强调消息跨越不同对象或角色的实际时间，而不仅仅只是关心消息的相对顺序。
（9）状态图（state diagram）：描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
（10）活动图（activity diagram）：将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模特别重要，并强调对象间的控制流程。
（11）部署图（deployment diagram）：描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
（12）制品图（artifact diagram）：描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
（13）包图（package diagram）：描述由模型本身分解而成的组织单元，以及它们的依赖关系
（14）交互概览图（interaction overview diagram）：是活动图和顺序图的混合物。
（2）：规则
UML用于描述事物的语义规则分别是为事物、关系和图命名。
给一个名字以特定含义的语境，即范围；
怎样使用或看见名字，即可见性；
事物如何正确、一致地相互联系，即完整性；
运行或模拟动态模型的含义是什么，即执行。
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分、它们的关联性、交互、机制和指导原则等这些提供系统设计的信息。
而具体来说，就是指5个系统视图，分别是逻辑视图、进程视图、实现视图、部署视图和用例视图。
（1）逻辑视图：以问题域的语汇组成的类和对象集合。
（2）进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。
（3）实现视图：对组成基于系统的物理代码的文件和构件进行建模。
（4）部署视图：把构件物理地部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。
（5）用例视图：最基本的需求分析模型。
其使用对应时间请参考：《软考架构师（8）——软件架构设计》中的图
（3）公共机制
公共机制是指达到特定目标的公共UML方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种。
二：面向对象分析
用例模型
分析模型
三：面向对象设计
面向对象设计是把分析阶段得到的需求转变成符合成本和质量要求的、抽象的系统实现方案的。
面向对象设计的一些基本准则是：模块化、抽象、信息隐藏、高内聚和低耦合。
下面是具体面向对象设计的原则：
（1）单一职责原则：（即尽可能一个类对应一个责任）这是模块内聚性在类和类的职责中的体现，如果一个类承担的职责过多，意味着这些职责耦合在一起，形成的很有可能是一个“杂凑类”，任一个职责的变化可能会削弱或者抑制该类完成其他职责的能力，并影响到构建、测试和部署等活动。通过业务分离可以对概念进行解耦，从而得到目的单一的类。
（2）开放-封闭原则。（即对于扩展是开放的，对于修改是封闭的）在模块本身不变动的情况下，通过改变模块周围的环境达到修改目的。遵循开放-封闭原则设计出的模块具有一个主要特征，即对于扩展是开放的，对于修改是封闭的。也就是说，模块的行为是可扩展的，当应用的需求改变时，在模块上进行扩展使其具有满足那些改变的新行为。当模块进行扩展时，不必改动模块的源代码或二进制代码。
（3）李氏（Liskov）替换原则。（即子类型必须能够替换掉它们的基类型）子类具有扩展父类的责任，而不是重写的责任。也就是说，基类的使用者不必为了使用子类而做任何其他的事情，他们可以在根本不了解子类的特殊性，甚至不必知道是否存在子类，存在哪些子类的情况下来调用基类的抽象方法。这样多态性才能顺利实现。事实上，正是Livkov替换原则，才使开放-封闭原则得以实现。因为正是子类的可替换性才使得基类的模块在无需修改的情况下就可以扩展。
（4）依赖倒置原则。高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。每个较高的层次都为它需要的服务声明一个抽象接口，较低的层次实现这个接口，每个高层类都通过该抽象接口使用下一层；要依赖于抽象，而不是具体实现。也可以这样说，要针对接口编程，不要针对实现编程。
（5）接口隔离原则。应当为客户端提供尽量小的单独的接口，而不是提供大的接口；使用多个专门的接口比使用单一的总接口要好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上的。这里的“接口”往往有两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构。在进行OOD的时候，一个重要的工作就是恰当的划分角色和角色对应的接口。将没有关系的接口合并在一起，是对角色和接口的“污染”。如果将一些看上去差不多的接口合并，并认为这是一种代码优化，这也是错误的。不同的角色应该交给不同的接口，而不能都交给一个接口。
（6）组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。组合相比于继承的好处：更大的灵活性而不会影响调用代码；更短的编译时间；适用性更广；较好的健壮性和安全性，更少的复杂性和脆弱性，更好的可维护性；能够在运行期创建新的对象。当然，耦合度的降低又会增加设计的难度、系统的复杂性以及实现的成本等，因此，在设计过程中，必须对这些因素综合考虑。
（7）迪米特（Demeter）原则：又叫最少知识法则（Least Knowledge Principle，LKP），就是说一个对象应当对其他对象有尽可能少的了解。遵循类之间的迪米特原则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。迪米特原则在类的设计上主要体现在：优先考虑将类设置成不变类，尽量降低类的访问权限，谨慎使用Serializable，尽量降低成员的访问权限。但遵循该原则，会在系统中造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。
四：面向对象测试
采用面向对象开发相对应的测试技术，它通常包括4个测试层次，从低到高排列分别是算法层、类层、模板层和系统层。
（1）算法层：测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。
（2）类层：测试封装在同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块（单元）测试。
（3）模板层：也称为主题层，测试一组协同工作的类或对象之间的相互作用。大体上相当于传统软件测试中的子系统测试，但是也有面向对象软件的特点（例如：对象之间通过发送消息相互作用）。
（4）系统层。把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。