OOA/OOD/OOP

　　Object-Oriented Analysis：面向对象分析方法

　　是在一个系统的开发过程当中进行了系统业务调查之后，按照面向对象的思想来分析问题。OOA与结构化分析有较大的区别。OOA所强调的是在系统调查资料的基础上，针对OO方法所须要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。

　　OOA（面向对象的分析）模型由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构，一种称为组装结构。分类结构就是所谓的通常与特殊的关系。组装结构则反映了对象之间的总体与部分的关系。

　　OOA在定义属性的同时，要识别实例链接。实例链接是一个实例与另外一个实例的映射关系。

　　OOA在定义服务的同时要识别消息链接。当一个对象须要向另外一对象发送消息时，它们之间就存在消息链接。

　　OOA 中的5个层次和5个活动继续贯穿在OOD（画向对象的设计）过程当中。OOD模型由4个部分组成。它们分别是设计问题域部分、设计人机交互部分、设计任务管理部分和设计数据管理部分。

　　1、OOA的主要原则。

　　（1）抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征，就叫做抽象。抽象是造成概念的必须手段。

　　抽象原则有两方面的意义：第一，尽管问题域中的事物是很复杂的，可是分析员并不须要了解和描述它们的一切，只须要分析研究其中与系统目标有关的事物及其本质性特征。第二，经过舍弃个体事物在细节上的差别，抽取其共同特征而获得一批事物的抽象概念。

　　抽象是面向对象方法中使用最为普遍的原则。抽象原则包括过程抽象和数据抽象两个方面。

　　过程抽象是指，任何一个完成肯定功能的操做序列，其使用者均可以把它看做一个单一的实体，尽管实际上它多是由一系列更低级的操做完成的。

　　数据抽象是根据施加于数据之上的操做来定义数据类型，并限定数据的值只能由这些操做来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操做（服务）结合为一个不可分的系统单位（即对象），对象的外部只须要知道它作什么，而没必要知道它如何作。

　　（2）封装就是把对象的属性和服务结合为一个不可分的系统单位，并尽量隐蔽对象的内部细节。

　　（3）继承：特殊类的对象拥有的其通常类的所有属性与服务，称做特殊类对通常类的继承。

　　在OOA中运用继承原则，就是在每一个由通常类和特殊类造成的通常—特殊结构中，把通常类的对象实例和全部特殊类的对象实例都共同具备的属性和服务，一次性地在通常类中进行显式的定义。在特殊类中再也不重复地定义通常类中已定义的东西，可是在语义上，特殊类却自动地、隐含地拥有它的通常类（以及全部更上层的通常类）中定义的所有属性和服务。继承原则的好处是：使系统模型比较简练也比较清晰。

　　（4）分类：就是把具备相同属性和服务的对象划分为一类，用类做为这些对象的抽象描述。分类原则其实是抽象原则运用于对象描述时的一种表现形式。

　　（5）聚合：又称组装，其原则是：把一个复杂的事物当作若干比较简单的事物的组装体，从而简化对复琐事物的描述。

　　（6）关联：是人类思考问题时常常运用的思想方法：经过一个事物联想到另外的事物。能令人发生联想的缘由是事物之间确实存在着某些联系。

　　（7）消息通讯：这一原则要求对象之间只能经过消息进行通讯，而不容许在对象以外直接地存取对象内部的属性。经过消息进行通讯是因为封装原则而引发的。在OOA中要求用消息链接表示出对象之间的动态联系。

　　（8）粒度控制：通常来说，人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。所以须要控制本身的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的具体的细节；考虑某部分的细节时则暂时撇开其他的部分。这就是粒度控制原则。

　　（9）行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各类行为每每相互依赖、相互交织。

　　2、面向对象分析产生三种分析模型

　　一、对象模型:对用例模型进行分析,把系统分解成互相协做的分析类,经过类图/对象图描述对象/对象的属性/对象间的关系,是系统的静态模型

　　二、动态模型:描述系统的动态行为,经过时序图/协做图描述对象的交互,以揭示对象间如何协做来完成每一个具体的用例,单个对象的状态变化/动态行为能够经过状态图来表达

　　三、功能模型(即用例模型à做为输入)。

　　3、OOA的主要优势

　　（1）增强了对问题域和系统责任的理解；

　　（2）改进与分析有关的各种人员之间的交流；

　　（3）对需求的变化具备较强的适应性；

　　（4）支持软件复用。

　　（5）贯穿软件生命周期全过程的一致性。

　　（6）实用性；

　　（7）有利于用户参与。

　   4、OOA方法的基本步骤

　　在用OOA具体地分析一个事物时，大体上遵循以下五个基本步骤：

　　第一步，肯定对象和类。这里所说的对象是对数据及其处理方式的抽象，它反映了系统保存和处理现实世界中某些事物的信息的能力。类是多个对象的共同属性和方法集合的描述，它包括如何在一个类中创建一个新对象的描述。

　　第二步，肯定结构（structure）。结构是指问题域的复杂性和链接关系。类成员结构反映了泛化-特化关系，总体-部分结构反映总体和局部之间的关系。

　　第三步，肯定主题（subject）。主题是指事物的整体概貌和整体分析模型。

　　第四步，肯定属性（attribute）。属性就是数据元素，可用来描述对象或分类结构的实例，可在图中给出，并在对象的存储中指定。

　　第五步，肯定方法（method）。方法是在收到消息后必须进行的一些处理方法：方法要在图中定义，并在对象的存储中指定。对于每一个对象和结构来讲，那些用来增长、修改、删除和选择一个方法自己都是隐含的（虽然它们是要在对象的存储中定义的，但并不在图上给出），而有些则是显示的。

 

 

 

                                                           OOD

　　面向对象设计（Object-Oriented Design，OOD）方法是OO方法中一个中间过渡环节。其主要做用是对OOA分析的结果做进一步的规范化整理，以便可以被OOP直接接受。

　　面向对象设计（OOD）是一种软件设计方法，是一种工程化规范。这是毫无疑问的。按照Bjarne Stroustrup的说法，面向对象的编程范式（paradigm）是[Stroustrup, 97]：

　　l 决定你要的类；

　　l 给每一个类提供完整的一组操做；

　　l 明确地使用继承来表现共同点。

　　由这个定义，咱们能够看出：OOD就是“根据需求决定所需的类、类的操做以及类之间关联的过程”。

　　OOD的目标是管理程序内部各部分的相互依赖。为了达到这个目标，OOD要求将程序分红块，每一个块的规模应该小到能够管理的程度，而后分别将各个块隐藏在接口（interface）的后面，让它们只经过接口相互交流。好比说，若是用OOD的方法来设计一个服务器-客户端（client-server）应用，那么服务器和客户端之间不该该有直接的依赖，而是应该让服务器的接口和客户端的接口相互依赖。

　　这种依赖关系的转换使得系统的各部分具备了可复用性。仍是拿上面那个例子来讲，客户端就没必要依赖于特定的服务器，因此就能够复用到其余的环境下。若是要复用某一个程序块，只要实现必须的接口就好了。

　　OOD是一种解决软件问题的设计范式（paradigm），一种抽象的范式。使用OOD这种设计范式，咱们能够用对象（object）来表现问题领域（problem domain）的实体，每一个对象都有相应的状态和行为。咱们刚才说到：OOD是一种抽象的范式。抽象能够分红不少层次，从很是归纳的到很是特殊的都有，而对象可能处于任何一个抽象层次上。另外，彼此不一样但又互有关联的对象能够共同构成抽象：只要这些对象之间有类似性，就能够把它们当成同一类的对象来处理。

　　1、OOD背景知识

　　计算机硬件技术却在飞速发展。从几十年前神秘的庞然大物，到如今随身携带的移动芯片；从每秒数千次运算到每秒上百亿次运算。当软件开发者们还在寻找能让软件开发生产力提升一个数量级的“银弹”[Brooks, 95]时，硬件开发的生产力早已提高了百倍千倍。

　　硬件工程师们可以如此高效，是由于他们都很懒惰。他们永远恪守“不要去从新发明轮子”的古训。Grady Booch把这些黑箱称为类属（class category），如今咱们则一般把它们称为“组件（component）”。

　　类属是由被称为类（class）的实体组成的，类与类之间经过关联（relationship）结合在一块儿。一个类能够把大量的细节隐藏起来，只露出一个简单的接口，这正好符合人们喜欢抽象的心理。因此，这是一个很是伟大的概念，由于它给咱们提供了封装和复用的基础，让咱们能够从问题的角度来看问题，而不是从机器的角度来看问题。

　　软件的复用最初是从函数库和类库开始的，这两种复用形式实际上都是白箱复用。到90年代，开始有人开发并出售真正的黑箱软件模块：框架（framework）和控件（control）。框架和控件每每还受平台和语言的限制，如今软件技术的新潮流是用SOAP做为传输介质的Web Service，它可使软件模块脱离平台和语言的束缚，实现更高程度的复用。可是想想，其实Web Service也是面向对象，只不过是把类与类之间的关联用XML来描述而已[Li, 02]。

　　在过去的十多年里，面向对象技术对软件行业起到了极大的推进做用。在能够预测的未来，它仍将是软件设计的主要技术——至少我看不到有什么技术能够取代它的。

　　2、OOD到底从哪儿来？

　　有不少人都认为：OOD是对结构化设计（Structured Design，SD）的扩展，其实这是不对的。OOD的软件设计观念和SD彻底不一样。SD注重的是数据结构和处理数据结构的过程。而在OOD中，过程和数据结构都被对象隐藏起来，二者几乎是互不相关的。不过，追根溯源，OOD和SD有着很是深的渊源。

　　1967年先后，OOD和SD 的概念几乎同时诞生，它们分别以不一样的方式来表现数据结构和算法。当时，围绕着这两个概念，不少科学家写了大量的论文。其中，由Dijkstra和 Hoare两人所写的一些论文讲到了“恰当的程序控制结构”这个话题，声称goto语句是有害的，应该用顺序、循环、分支这三种控制结构来构成整个程序流程。这些概念发展构成告终构化程序设计方法；而由Ole-Johan Dahl所写的另外一些论文则主要讨论编程语言中的单位划分，其中的一种程序单位就是类，它已经拥有了面向对象程序设计的主要特征。

　　这两种概念马上就分道扬镳了。在结构化这边的历史你们都很熟悉：NATO会议采纳了Dijkstra的思想，整个软件产业都赞成goto语句的确是有害的，结构化方法、瀑布模型从70年代开始大行其道。同时，无数的科学家和软件工程师也帮助结构化方法不断发展完善，其中有不少今天足以使咱们振聋发聩的名字，例如Constantine、Yourdon、DeMarco和Dijkstra。有很长一段时间，整个世界都相信：结构化方法就是拯救软件工业的 “银弹”。固然，时间最后证实了一切。

　　而此时，面向对象则在研究和教育领域缓慢发展。结构化程序设计几乎能够应用于任何编程语言之上，而面向对象程序设计则须要语言的支持[1]，这也妨碍了面向对象技术的发展。实际上，在60年代后期，支持面向对象特性的语言只有Simula-67这一种。到70年代，施乐帕洛阿尔托研究中心（PARC）的 Alan Key等人又发明了另外一种基于面向对象方法的语言，那就是大名鼎鼎的Smalltalk。可是，直到80年代中期，Smalltalk和另外几种面向对象语言仍然只停留在实验室里。

　　到90年代，OOD忽然就风靡了整个软件行业，这绝对是软件开发史上的一次革命。不过，登高才能望远，新事物老是站在旧事物的基础之上的。70年代和80年代的设计方法揭示出许多有价值的概念，谁都不能也不敢忽视它们，OOD也同样。

　　3、OOD和传统方法有什么区别？

　　还记得结构化设计方法吗？程序被划分红许多个模块，这些模块被组织成一个树型结构。这棵树的根就是主模块，叶子就是工具模块和最低级的功能模块。同时，这棵树也表示调用结构：每一个模块都调用本身的直接下级模块，并被本身的直接上级模块调用。

　　那么，哪一个模块负责收集应用程序最重要的那些策略？固然是最顶端的那些。在底下的那些模块只管实现最小的细节，最顶端的模块关心规模最大的问题。因此，在这个体系结构中越靠上，概念的抽象层次就越高，也越接近问题领域；体系结构中位置越低，概念就越接近细节，与问题领域的关系就越少，而与解决方案领域的关系就越多。

　　可是，因为上方的模块须要调用下方的模块，因此这些上方的模块就依赖于下方的细节。换句话说，与问题领域相关的抽象要依赖于与问题领域无关的细节！这也就是说，当实现细节发生变化时，抽象也会受到影响。并且，若是咱们想复用某一个抽象的话，就必须把它依赖的细节都一块儿拖过去。

　　而在OOD中，咱们但愿倒转这种依赖关系：咱们建立的抽象不依赖于任何细节，而细节则高度依赖于上面的抽象。这种依赖关系的倒转正是OOD和传统技术之间根本的差别，也正是OOD思想的精华所在。

　　4、OOD步骤

　　细化重组类

　　细化和实现类间关系,明确其可见性

　　增长属性,指定属性的类型与可见性

　　分配职责,定义执行每一个职责的方法

　　对消息驱动的系统,明确消息传递方式

　　利用设计模式进行局部设计

　　画出详细的类图与时序图

　　5、OOD设计过程当中要展开的主要几项工做

　　（一）对象定义规格的求精过程

　　对于OOA所抽象出来的对象-＆-类以及聚集的分析文档，OOD须要有一个根据设计要求整理和求精的过程，使之更能符合OOP的须要。这个整理和求精过程主要有两个方面：一是要根据面向对象的概念

　　模型整理分析所肯定的对象结构、属性、方法等内容，改正错误的内容，删去没必要要和重复的内容等。二是进行分类整理，以便于下一步数据库设计和程序处理模块设计的须要。整理的方法主要是进行归

　　类，对类一＆一对象、属性、方法和结构、主题进行归类。

　　（二）数据模型和数据库设计

　　数据模型的设计须要肯定类-＆-对象属性的内容、消息链接的方式、系统访问、数据模型的方法等。最后每一个对象实例的数据都必须落实到面向对象的库结构模型中。

　　（三）优化

　　OOD的优化设计过程是从另外一个角度对分析结果和处理业务过程的整理概括，优化包括对象和结构的优化、抽象、集成。

　　对象和结构的模块化表示OOD提供了一种范式，这种范式支持对类和结构的模块化。这种模块符合通常模块化所要求的全部特色，如信息隐蔽性好，内部聚合度强和模块之间耦合度弱等。

　　集成化使得单个构件有机地结合在一块儿，相互支持。

　　6、OO方法的特色和面临的问题

　　OO方法以对象为基础，利用特定的软件工具直接完成从对象客体的描述到软件结构之间的转换。这是OO方法最主要的特色和成就。OO方法的应用解决了传统结构化开发方法中客观世界描述工具与软

　　件结构的不一致性问题，缩短了开发周期，解决了从分析和设计到软件模块结构之间屡次转换映射的繁杂过程，是一种颇有发展前途的系统开发方法。

　　可是同原型方法同样,OO方法须要必定的软件基础支持才能够应用，另外在大型的MIS开发中若是不经自顶向下的总体划分，而是一开始就自底向上的采用OO 方法开发系统，一样也会形成系统结构不合理、各部分关系失调等问题。因此OO方法和结构化方法目前还是两种在系统开发领域相互依存的、不可替代的方法。

　　7、OOD能给我带来什么？

　　问这个问题的人，脑子里一般是在想“OOD能解决全部的设计问题吗？”没有银弹。OOD也不是解决一切设计问题、避免软件危机、捍卫世界和平……的银弹。OOD只是一种技术。可是，它是一种优秀的技术，它能够很好地解决目前的大多数软件设计问题——固然，这要求设计者有足够的能力。

　　OOD可能会让你头疼，由于要学会它、掌握它是很困难的；OOD甚至会让你失望，由于它也并不成熟、并不完美。OOD也会给你带来欣喜，它让你能够专一于设计，而没必要操心那些细枝末节；OOD也会使你成为一个更好的设计师，它能提供给你很好的工具，让你能开发出更坚固、更可维护、更可复用的软件。

 

 

 

                                                               OOP

　面向对象编程（Object Oriented Programming，OOP，面向对象程序设计）是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个可以起到子程序做用的单元或对象组合而成。OOP 达到了软件工程的三个主要目标：重用性、灵活性和扩展性。为了实现总体运算，每一个对象都可以接收信息、处理数据和向其它对象发送信息。OOP 主要有如下的概念和组件：

　　组件 － 数据和功能一块儿在运行着的计算机程序中造成的单元，组件在 OOP 计算机程序中是模块和结构化的基础。

　　抽象性 － 程序有能力忽略正在处理中信息的某些方面，即对信息主要方面关注的能力。

　　封装 － 也叫作信息封装：确保组件不会以不可预期的方式改变其它组件的内部状态；只有在那些提供了内部状态改变方法的组件中，才能够访问其内部状态。每类组件都提供了一个与其它组件联系的接口，并规定了其它组件进行调用的方法。

　　多态性 － 组件的引用和类集会涉及到其它许多不一样类型的组件，并且引用组件所产生的结果得依据实际调用的类型。

　　继承性 － 容许在现存的组件基础上建立子类组件，这统一并加强了多态性和封装性。典型地来讲就是用类来对组件进行分组，并且还能够定义新类为现存的类的扩展，这样就能够将类组织成树形或网状结构，这体现了动做的通用性。

　　因为抽象性、封装性、重用性以及便于使用等方面的缘由，以组件为基础的编程在脚本语言中已经变得特别流行。Python 和 Ruby 是最近才出现的语言，在开发时彻底采用了 OOP 的思想，而流行的 Perl 脚本语言从版本5开始也慢慢地加入了新的面向对象的功能组件。用组件代替“现实”上的实体成为 JavaScript（ECMAScript） 得以流行的缘由，有论证代表对组件进行适当的组合就能够在英特网上代替 HTML 和 XML 的文档对象模型（DOM）。

设计模式、技术和直觉构成严峻的挑战。这是选择编程语言以前必须认识到的，尽管不一样语言的设计特性可能促进或者阻碍这一转化。

　　在网络应用的增加中，一个很重要的部分是小型移动设备和特殊Internet设备的爆炸性增加。这些设备各有各的操做系统，或者只在某种特定的设备领域内有共同的操做系统。咱们如今还能够一一列举出这些设备——家庭接入设备、蜂窝电话、电子报纸、PDA、自动网络设备等等。可是这些设备领域的数量和深刻程度将会很快变得难以估量。咱们都知道这个市场大得惊人，PC的兴起与之相比不太小菜一碟。所以在这些设备的应用程序市场上，竞争将会至关残酷。获胜的重要手段之一，就是尽快进入市场。开发人员须要优秀的工具，迅速高效地撰写和调试他们的软件。平台无关性也是制胜秘诀之一，它使得程序员可以开发出支持多种设备平台的软件。

　　我预期的另外一个变化是，咱们对于代码(Java)和数据(XML)协同型应用程序的开发能力将会不断提升。这种协同是开发强大应用程序的核心目标之一。咱们从XML的迅速流行和ebXML规范的进展中，已经看到了这个趋势。ebXML是一个针对电子商务和国际贸易的，基于XML的开放式基础构架，由联合国贸易促进和电子商务中心(UN/CEFACT)与结构性信息标准推动组织(OASIS)共同开发。

　　咱们可否指望出现一个真正的面向组件(component-oriented)的语言？它的创造者会是谁呢？

　　Stroustrup: 我怀疑，这个领域中之因此缺少成果，正是由于人们——主要是那些非程序员们——对“组件”这个意义含糊的字眼寄予了太多的指望。这些人士梦想，有朝一日，组件会以某种方式把程序员赶出历史舞台。之后那些称职的“设计员”只需利用预先调整好的组件，把鼠标拖一拖放一放，就把系统组合出来。对于软件工具厂商来讲，这种想法还有另外一层意义，他们认为，到时候只有他们才保留有必要的技术，有能力编写这样的组件。

　　这种想法有一个最基本的谬误：这种组件很难得到普遍欢迎。一个单独的组件或框架(framework)，若是可以知足一个应用程序或者一个产业领域对所提出的大部分要求的话，对于其制造者来讲就是划算的产品，并且技术上也不是很困难。但是该产业内的几个竞争者很快就会发现，若是全部人都采用这些组件，那么彼此之间的产品就会变得天下大同，没什么区别，他们将沦为简单的办事员，主要利润都将钻进那些组件/框架供应商的腰包里！

　　小“组件”颇有用，不过产生不了预期的杠杆效应。中型的、更通用的组件很是有用，可是构造时须要非同寻常的弹性。