1.面向对象开发面向对象开发过程完整生命周期:面向对象分析(OOA)面向对象设计(OOD)面向对象程序设计(OOP)面向对象测试(OOT)重要性: 是现代软件开发的主流方法比结构化方法更重要(1)对象:由数据及其操作所构成的封装体是系统中用来描述客观事务的一个实体是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。(2)类:现实世界中实体的形式化描述类将该实体的属性(数据)和操作(函数)封装在一起。对象是类的实例类是对象的模板。类可以分为三种:实体类、接口类(边界类)和控制类。实体类的对象表示现实世界中真实的实体如人、物等。接口类(边界类) 的对象为用户提供一种与系统合作交互的方式分为人和系统两大类其中人的接口可以是显示屏窗口、Web 窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统或者从其他系统接收数据。控制类的对象用来控制活动流充当协调者(3)抽象:通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征忽略次要特征。一个对象是现实世界中一个实体的抽象一个类是一组对象的抽象抽象是一种单一化的描述它强调给出与应用相关的特性抛弃不相关的特性。(4)封装:是一种信息隐蔽技术将相关的概念组成一个单元模块并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象对数据的访问或修改只能通过对象对外提供的接口进行。(5) 继承:表示类之间的层次关系(父类与子类)这种关系使得某类对象可以继承另外一类对象的特征又可分为单继承和多继承。(6)多态:不同的对象收到同一个消息时产生完全不同的结果。包括参数多态 (不同类型参数多种结构类型)、包含多态(父子类型关系)、过载多态(类似于重载一个名字不同含义)强制多态(强制类型转换) 四种类型。多态由继承机制支持将通用消息放在抽象层具体不同的功能实现放在低层。(7)接口:描述对操作规范的说明其只说明操作应该做什么并没有定义操作如何做。(8)消息:体现对象间的交互通过它向目标对象发送操作请求(9)覆盖:子类在原有父类接口的基础上用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法(10)函数重载:与覆盖要区分开函数重载与子类父类无关且函数是同名不同参数。(11)绑定是一个把过程调用和响应调用所需要执行的代码加以结合的过程在一般的程序设计语言中绑定是在编译时进行的叫作静态绑定。动态绑定则是在运行时进行的因此一个给定的过程调用和代码的结合直到调用发生时才进行。对象定义: 由数据和操作数据的函数封装组成的实体是构成系统的基本单元类分类:实体类对应现实世界中真实存在的实体边界类用于与系统外部交互如用户界面、Web窗体控制类协调其他类的工作抽象特性: 通过提取主要特征、忽略次要特征来实现对象的抽象抽象是面向对象的核心特性面向对象的分析:是为了·确定问题域理解问题。包含五个活动:认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。1面向对象分析的目的与活动核心目的确定问题域并建立逻辑模型五大活动对象认定识别系统中的关键对象对象组织确定对象属性和内部结构交互描述定义对象间关系和作用操作确定明确对象行为和方法信息定义完善对象内部数据细节建模成果通过这五个步骤建立完整的系统逻辑模型2面向对象需求建模的两种模型模型对比用例模型描述系统功能需求对应结构化方法中的功能模型分析模型描述系统数据结构对应结构化方法中的数据模型结构化对比数据模型E-R图行为模型状态转换图功能模型数据流图3用例模型建立步骤必要步骤识别系统参与者合并需求获得用例细化用例描述可选步骤调整用例模型核心关系包含关系扩展关系泛化关系4分析模型建立步骤关键流程定义概念类识别类间关系关联/聚合/组合/依赖/泛化为类添加职责属性和方法建立交互图动态行为建模模型组成静态模型类图、对象图动态模型活动图、序列图面向对象的设计:是设计分析模型和实现相应源代码设计问题域的解决方案与技术相关。OOD同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。设计准则抽象信息隐蔽功能独立模块化分析模型构成顶层架构图用例与用例图领域概念模型设计模型构成软件体系结构图包图表示用例实现图交互图表示精确类图状态图复杂对象活动图流程描述术语注意体系结构与架构是同一概念都对应architecture面向对象的设计原则:(1)单一责任原则。就一个类而言应该仅有一个引起它变化的原因。即当需要修改某个类的时候原因有且只有一个让一个类只做一种类型责任(2)开放一封闭原则。软件实体 (类、模块、函数等) 应该是可以扩展的即开放的;但是不可修改的即封闭的。(3)里氏替换原则。子类型必须能够替换掉他们的基类型。即在任何父类可以出现的地方都可以用子类的实例来赋值给父类型的引用。(4)依赖倒置原则。抽象不应该依赖于细节细节应该依赖于抽象。即高层模块不应该依赖于低层模块二者都应该依赖于抽象。(5)接口分离原则。不应该强迫客户依赖于它们不用的方法。接口属于客户不属于它所在的类层次结构。即:依赖于抽象不要依赖于具体同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。1单一责任原则定义一个类应该仅有一个引起它变化的原因本质每个类只承担一种类型责任优势修改影响范围明确避免牵一发而动全身举例用户管理类不应同时处理登录验证和数据存储2开放-封闭原则双重要求开放支持功能扩展通过继承/接口实现封闭禁止修改已有核心代码实施建议旧代码注释保留而非删除新增代码独立扩展典型场景框架设计时预留扩展点3里氏替换原则核心规则子类必须能完全替代父类技术实现子类实例可赋值给父类引用变量违反后果多态调用时出现行为不一致示例正方形继承长方形时需重写setWidth()保持数学特性4依赖倒置原则依赖关系正向高层模块→低层模块错误倒置共同依赖抽象接口正确编程实践定义抽象接口作为中间层具体实现类实现统一接口记忆口诀“要依赖抽象不要依赖具体”5接口分离原则核心思想接口的契约与实现相分离负面案例强制实现类继承不需要的方法正确做法按功能划分细粒度接口实现类按需组合接口与依赖倒置区别强调接口最小化而非抽象方向一般来说对面向对象软件的测试可分为下列4 个层次进行。(1)算法层。测试类中定义的每个方法基本上相当于传统软件测试中的单元测试(2)类层。测试封装在同一个类中的所有方法与属性之间的相互作用。在向面对象软件中类是基本模块因此可以认为这是面向对象测试中所特有的模块测试(3)模板层。测试一组协同工作的类之间的相互作用大体上相当于传统软件测试中的集成测试但是也有面向对象软件的特点 (例如对象之间通过发送消息相互作用)。(4)系统层。把各个子系统组装成完整的面向对象软件系统在组装过程中同时进行测试。2.统一建模语言UMLUML(统一建模语言): 是一种可视化的建模语言而非程序设计语言支持从需求分析开始的软件开发的全过程。从总体上来看UML的结构包括构造块、规则和公共机制三个部分(1)构造块。UML有三种基本的构造块分别是事物 (thing)、关系和图 (diagram)。事物是UML的重要组成部分关系把事物紧(relationship)密联系在一起图是多个相互关联的事物的集合。(2)公共机制。公共机制是指达到特定目标的公共UML方法。(3)规则。规则是构造块如何放在一起的规定结构事物:模型的静态部分如类、接口、用例、构件等;行为事物:模型的动态部分如交互、活动、状态机;分组事物:模型的组织部分如包;注释事物:模型的解释部分依附于一个元素或组元素之上对其进行约束或解释的简单符号依赖:一个事物的语义依赖于另一个事物的语义的变化而变化关联:是一种结构关系描述了一组链链是对象之间的连接。分为组合和聚合都是部分和整体的关系其中组合事物之间关系更强。两个类之间的关联实际上是两个类所扮演角色的关联因此两个类之间可以有多个由不同角色标识的关联。泛化:一般/特殊的关系子类和父类之间的关系实现:一个类元指定了另一个类元保证执行的契约UML2.0图书上是13种有的说法还包含制品图一共14种了解即可总分类如下:类图:静态图为系统的静态设计视图展现一组对象、接口、协作和它们之间的关系。UML类图如下:对象图:静态图展现某一时刻一组对象及它们之间的关系为类图的某一快照。在没有类图的前提下对象图就是静态设计视图。如下:用例图:静态图展现了一组用例、参与者以及它们之间的关系。用例图中的参与者是人、硬件或其他系统可以扮演的角色;用例是参与者完成的一系列操作用例之间的关系有扩展、包含、泛化。如下:序列图:即顺序图动态图是场景的图形化表示描述了以时间顺序组织的对象之间的交互活动。有同步消息 (进行阻塞调用调用者中止执行等待控制权返回需要等待返回消息用实心三角箭头表示)异步消息(发出消息后继续执行不引起调用者阻塞也不等待返回消息由空心箭头表示)、返回消息 (由从右到左的虚线箭头表示)三种。如下:通信图:动态图即协作图强调参加交互的对象的组织。如下状态图:动态图展现了一个状态机描述单个对象在多个用例中的行为包括简单状态和组合状态。转换可以通过事件触发器触发事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念如下:图中方框代表状态箭头上的代表触发事件实心圆点为起点和终点。活动图:动态图是一种特殊的状态图展现了在系统内从一个活动到另一个活动的流程。活动的分岔和汇合线是一条水平粗线。牢记下图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个分岔的分支数代表了可同时运行的线程数。活动图中能够并行执行的是在一个分岔粗线下的分支上的活动构件图(组件图静态图为系统静态实现视图展现了一组构件之间的组织和依赖。如下:部署图:静态图为系统静态部署视图部署图物理模块的节点分布。它与构件图相关通常一个结点包含一个或多个构件。其依赖关系类似于包依赖因此部署组件之间的依赖是单向的类似于包含关系。如下:UML 41视图(1) 逻辑视图。逻辑视图也称为设计视图它表示了设计模型中在架构方面具有重要意义的部分即类、子系统、包和用例实现的子集(2)进程视图。进程视图是可执行线程和进程作为活动类的建模它是逻辑视图的一次执行实例描述了并发与同步结构。(3)实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模(4)部署视图。部署视图把构件部署到一组物理节点上表示软件到硬件的映射和分布结构(5)用例视图。用例视图是最基本的需求分析模型3.设计模式架构模式:软件设计中的高层决策例如C/S结构就属于架构模式架构模式反映了开发软件系统过程中所作的基本设计决策。设计模式:每一个设计模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这样你就能一次又一次地使用该方案而不必做重复劳动设计模式的核心在于提供了相关问题的解决方案使得人们可以更加简单方便的复用成功的的设计和体系结构。四个基本要素:模式名称、问题(应该在何时使用模式)、解决方案(设计的内容)、效果 (模式应用的效)惯用法:是最低层的模式关注软件系统的设计与实现实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式即语言的惯用法。例如引用一计数就是C语言中的一种惯用法。