OO(Object Oriented)
这是一个故事:
"工程师修了一条隧道,隧道的一端就是美丽的风景,很多人会开车通过隧道.虽然隧道内已经有灯了,但是设计者担心隧道可能会停电,所以在隧道的入口立了牌子,提醒驾驶员进入隧道前开灯.可是由此却使得驾驶员由于看到美丽的风景而忘记关灯的情况的发生."
引来对ooa,ood,oop的理解;
分析师拿到了政府，民众，组织，社团等的需求，这里泛指所有来自客户的需求了；了解需求，分析需求，分析技术实现等，得出一个结论：要在这里修条隧道；于是分析师，系统分析师，架构设计师出现了，他们干的工作就分析出来一个方案，即项目需求吧，他们的身份就是OOA了。
OOA是Object-Oriented Analysis(面向对象分析)
分析师们分析结果出来后，形成了最早的需求模型；可能是一个草图，一张可行性分析XX报告；设计师们拿到这个模型进行细化，模块化，定义所有的细节，也就是详图，或是详细的需求分析规格书了，在这里，可能会有隧道的位置，长度，宽度，高度，容量，光线，材料，设备，电子眼，安全等，这里就是具体的需求文档了。设计师的设计工作完成了，他们就是OOD。
OOD是Object Oriented Design(面向对象设计)
OOP就是施工队了，他们按照设计图的要求完成隧道工程，包括质量，容量，安全等测试，也就是完成项目的实际操作部分，在项目里就是coding的工作和testing的工作。到此为止，隧道就完成了，驾驶员也可以说成是testing的一员，他们进行体验，体验完了，没问题，oop的工作也就结束了，我们可以收工了。
OOP是Object Oriented Programming (面象对象程序设计)
面向对象的方法：
包括OOA、OOD、OOP，面向对象方法的一些基本概念
1、对象 ；2、类；3、继承；
4、封装；对象之间只能通过接口进行信息交流，外部不能对对象中的数据随意进行访问。封装的优点：好的封装能减少耦合；类内部的实现可以自由改变；一个类有更清晰的接口；
5、消息；一个消息通常包括接收对象名、调用的操作名和适当的参数（如有必要）
6、多态性；多态性是指同一个操作作用于不同的对象时可以有不同的解释，并产生不同的执行结果。与多态性密切相关的一个概念就是动态绑定。静态绑定：（final、static、private）在程序执行前已经被绑定，也就是说在编译过程中就已经知道这个方法是哪个类的方法，此时由编译器获取其他连接程序实现。动态绑定：每次调用方法都要进行搜索，时间开销太大，所以虚拟机预先为每个类创建一个方法表（method table），其中列出了所有方法的签名和实际调用的方法。这样在调用方法的时候，只需要查找这个表即可。
UML，它的作用域不限于支持面向对象的分析（OOA）与设计(OOD)，还支持从需求分析开始的软件开发的全过程。
OOD（含设计模式）的基本原则原则，模块化、抽象、信息隐藏、高内聚、低耦合。
1、单一职责原则，这是模块内聚性在类和类的职责中的体现，如果一个类承担的职责过多，意味着这些职责耦合在一起，形成的很有可能是一个“杂凑类”。通过业务分离可以对概念进行解耦，从而得到目的单一的类。
2、开放-封闭原则，在模块本身不变动的情况下，通过改变模块周围的环境达到修改目的。这个原则的特征是对于扩展是开放的，对于修改是封闭的。也就是说，模块的行为是可扩展的，当应用的需求改变时，在模块上进行扩展使其具有满足那些改变的新行为。当模块进行扩展时，不必改动模块的源代码或二进制。
3、李氏（LisKov）替换原则，子类型必须能够替换掉它们的基类型。子类具有扩展父类的责任，而不是重写的责任。也就是说，基类的使用者不必为了使用子类而做任何其他的事情，他们可以在根本不了解子类的特殊性，甚至不必知道是否存在子类，存在哪些子类的情况下来调用基类的抽象方法。这样多态性才能顺利实现。事实上，正式Livkov替换原则，才使开放-封闭原则得以实现。因为正是子类的可替换性才使得基类的模块在无需修改的情况下就可以扩展。可以考虑抽象类的特点以及与接口的区别。
4、依赖倒置原则，高层模块不应该依赖底层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。每个较高的层次都为它需要的服务声明一个抽象接口，较低的层次实现这个接口，每个高层类都通过该抽象接口使用下一层；要依赖抽象，而不是具体实现。也可以这样说，要针对接口编程，不要针对实现编程。
5、接口隔离原则，应当为客户端提供尽量小的单独的接口，而不是提供大的接口；“接口”往往两种不同的含义：一种是指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象；另外一种是指某种语言具体的“接口”定义，有严格的定义和结构。在进行OOD的时候，一个重要的工作就是恰当的划分角色和角色对应的接口。
6、组合重用原则，要尽量使用组合，而不是继承关系达到重用目的。
7、迪米特（Demeter）原则，又称最少知识法则（Least Knowledge Principe，LKP），就是说一个对象应当对其他对象有尽可能少的了解。遵循Demeter会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。在类的设计上主要体现在：优先考虑将类设置成不变类，尽量降低类的访问权限，谨慎使用Serializable，尽量降低成员的访问权限。
UML的结构
包括基本构造块、支配这些构造块如何放在一起的规则（架构）和一些运用于整个UML的机制。
1、构造块：UML有3种构造块，分别是事物、关系、图。关系把事物紧密联系在一起，图是很多有相关的事物的组。
3、公共机制：是指达到特定目标的公共UML方法，包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展 机制4种。规格说明是事物语义的文本描述，它是模型的真正的核心；UML为每一个事物设置了一个简单的记号，还可以通过修饰来表达更多的信息；公共分类包括类与对象（类表示概念，而对象表示具体的实体）、接口和实现（接口用来定义契约，而实现是具体的内容）两组公共分类；扩展机制包括约束（添加新规则来扩展事物的语义）、构造型（用于定义新的事物）、标记值（添加新的特殊信息来扩展事物的规格说明）
2、规则：系统设计的信息，具体包括：
逻辑视图：以问题域的语汇组成的类和对象的集合。
进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。
实现视图：对组成基于系统的物理代码的文件和构件进行建模。
部署视图：把构件 物理地 部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。
用例视图：最基本的需求分析模型。
UML中的事物也称为建模元素
结构事物：在模型中属于最静态的部分，代表概念上等或物理上的元素，主要有7种结构事物，类、接口、协作、用例、活动类、构件、结点
行为事物：是UML模型中的动态部分。它们是模型的动词，代表时间和空间上的动作。主要有两种：
第一种是交互（内部活动），交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而成的动作。第二种是状态机，由一系列对象的状态组成。
分组事物：是UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中被分解。总共只有一种分组事物，称为包。包是一种将有组织的事物分组的机制。与构件（存在于运行时）不同的是包纯粹是一种概念上的东西，值存在于开发阶段。
注释事物：是UML模型的解释部分。
UML用关系把事物结合在一起，有4种：
依赖（dependencies）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
关联（association）：一种描述一组对象之间连接的结构关系，如聚合关系（描述了整体和部分件的结构关系）。
泛化（generalization）：一种一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
实现（realization）：类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
UML2.0使用了14种图，如下：
1、类图：类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。
2、对象图：
3、构件图：组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件（例如，库函数）的依赖关系。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次2上显示。
4、组合结构图：
5、用例图：描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。
6、顺序图（时序）：序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的
7、通信图（协作）：和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图；这两种图合称为交互图。
8、定时图：
9、状态图：描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知 一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。
10、活动图：描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
11、部署图：
12、制品图：
13、包图：
14、交互概览图：
浙公网安备 33010602011771号