笔记代码学习与

OOAD与UML学习目标理解与掌握面向对象的概念与方法使用UML完成面向对象的分析与设计工作了解OO的设计原则及一些典型的设计模式课程结构OOAD概述UML需求与初始分析分析阶段的静态建模分析阶段的动态建模OO设计原则与模式设计阶段的静态建模概念介绍分析阶段设计阶段设计阶段的动态建模系统设计课程目标理解面向对象程序设计的概念描述面向对象程序设计的特点列举在迭代、递增软件生命周期中的主要阶段及工作流列举UML的基本图形与元素了解如何收集与整理需求标注对象模型与类定义类的行为，使用多态与其它设计技术标注与分析动态模型定义类的属性、操作与关系课程目标理解OO的设计原则掌握一些基本的设计模式了解如何定义与划分系统Module1:OOAD概述学习目标描述面向对象的概念描述面向对象的分析阶段与设计阶段的差别描述软件开发的一些传统方式解释迭代、递增的项目开发生命周期标注并列举系统开发过程中各阶段所涉及的工作流什么是面向对象？面向对象（Object-Orientation

，简称OO）是一种系统建模技术面向对象编程（Object-Orientation

Programming，简称OOP）是按照OO的方法学来开发程序的过程通过分析系统内对象的交互来描述或建模一个系统交互的对象最终以类的形式组织OO的方法由三部分组成

—过程

—标识

—规则对象是一个客观存在的、唯一的实体是面向对象编程过程中分析与解决问题的出发点与基础拥有自己的标识、数据与行为可以简单或复杂可以抽象或具体在OOP中是一个类的动态实例如Student——id,name,age(attributes) ——setName,getName,countScore(methods) ——newStudent()类类是对象的模板对象通过类实例化产生一个类可以创建多个对象class1obj1obj3obj2OOADOOAD是根据OO的方法学，对软件系统进行分析和设计的过程

——OOA分析阶段

——OOD设计阶段定义OOA阶段分析阶段主要解决以下问题

——建立针对业务问题域的清晰视图

——列出系统必须要完成的核心任务

——针对问题域建立公共词汇表

——列出针对此问题域的最佳解决方案此阶段要解决的核心问题是“Whattodo?”定义OOD阶段设计阶段主要解决以下问题

——如何解决具体的业务问题

——引入系统工作所需的支持元素

——定义系统的实现策略此阶段要解决的核心问题是“Howtodo?”OOP的主要特征抽象(abstract)封装(encapsulation)继承(inheritance)多态(polymorphism)关联(association)聚合(aggregation)组合(composition)内聚与耦合(cohesion&coupling)抽象忽略掉一个对象或实体的细节而只关注其本质特征的过程简化功能与格式帮助用户与对象交互封装隐藏数据和实现提供公共方法供用户调用功能对象的两种视图

——外部视图：对象能做的工作

——内部视图：对象如何完成工作

——电视机：调节音量继承通过存在的类型定义新类型的机制通常在两个类型之间存在“isa”或“kindof”这样的关系通过继承可实现代码重用，另外继承也是多态的基础如苹果“isa”水果多态一个名称，多种形式一个类中的方法重载就是一种多态基于继承的多态调用方法时根据所给对象的不同选择不同的处理方式如Football——play()：使用脚来完成Basketball——play()：使用手来完成给出一个具体的足球或篮球，用户自动知道该使用谁的方式去执行play()关联对象之间交互时的一种引用方式当一个对象通过对另一个对象的引用去使用另一个对象的服务或操作时，两个对象之间便产生了关联如person使用computer，person与computer之间就存在了关联关系聚合关联关系的一种，一个对象成为另外一个对象的组成部分是一种关系较强的关联在两个对象之间存在“hasa”这样的关系，一个对象作为另一个对象的属性存在，在外部对象被生产时，可由客户端指定与其关联的内部对象如汽车与轮胎，轮胎作为汽车的一个组成部分，它和汽车可以分别生产以后装配起来使用，但汽车可以换新轮胎，轮胎也可以卸下来给其它汽车使用组合当一个对象包含另一个对象时，外部对象负责管理内部对象的生命周期的情况关联关系中最为强烈的一种内部对象的创建由外部对象自己控制外部对象不存在时，内部对象也不能存在如电视机与CRT内聚与耦合内聚：度量一个类独立完成某项工作的能力耦合：度量系统内或系统之间依赖关系的复杂度设计原则：增加内聚，减少耦合练习给出下列对象，完成对对象的抽象功能描述

Car，Person，Employee，Bankaccount给出下列对象，通过继承的方式找出对象之间存在的公共功能

ElectricalAppliances Audio Hi-fi,Radio,Walkman RefrigerationAppliances Fridge,Freezer练习 Telephone Fixed,Cordless,Cellular描述以下方法在不同设备上的实现

——所有的电器设备都有“turnon”和“turnoff”方法

——所有的音频设备都有“adjustVolum”方法

——所有的冰箱设备都有“adjustTemperature”方法

——所有的电话设备都有“dial”与“hangup”方法开发过程概述传统开发过程

——瀑布模型统一软件开发过程（USDP）传统开发过程瀑布模型RequirementsAnalysisDesignImplementationTestTimeOOAD的开发过程大项目分解为一些子项目使用UML工具统一软件开发过程是一个迭代、递增的开发过程迭代、递增的项目生命周期项目是迭代、递增的迭代指生命周期中的一个步骤迭代导致“递增”或者是整个项目的增长大项目分解为子项目迭代、递增的项目生命周期在每一个迭代的阶段，应该做以下工作

——选择并分析相关用例

——根据所选架构进行设计

——在组件层次实现设计

——验证组件满足用例的需要当一次迭代满足目标后，开发进入下一个迭代周期迭代、递增生命周期的主要阶段Inception—startupElaboration—refineConstruction—implementTransition—promotion每一个周期包含一次或多次迭代一个阶段的结束称之为“里程碑”（milestone）过程图初始化阶段该阶段的增量集中于：

——项目启动

——建立业务模型

——定义业务问题域

——找出主要的风险因素

——定义项目需求的外延

——创建业务问题域的相关说明文档细化阶段本阶段的增量集中于：

——高层的分析与设计

——建立项目的基础框架

——监督主要的风险因素

——制订达成项目目标的创建计划构建阶段本阶段的增量集中于：

——代码及功能的实现移交阶段本阶段的增量集中于：

——向用户发布产品

——beta测试

——执行性能调优，用户培训和接收测试每一个阶段所含工作流每一次递增都由5部分工作流组成

——需求与初始分析

——分析

——设计

——实现

——测试

——每一次迭代执行工作流的深度不同

——早期的迭代在深度上覆盖初始工作流，后期迭代在深度上覆盖后期工作流

——80/20原则迭代工作流RequirementsAnalysisDesignImplementationTestTime迭代、递增生命周期的优势降低成本便于更好地维护项目进度便于团队的协作开发便于适应用户需求的动态变化CheckYourProgress描述面向对象的概念描述面向对象的分析阶段与设计阶段的差别描述软件开发的一些传统方式解释迭代、递增的项目开发生命周期标注并列举系统开发过程中各阶段所涉及的工作流Module2:UML学习目标描述UML在OOAD过程中的作用熟悉UML中的九种基本图形解释与使用“包”的标记了解UML中的扩展机制UML的定义统一建模语言（UML）是一种图形化的语言，它可以帮助我们在OOAD过程中标识元素、构建模块、分析过程并可通过文档说明系统中的重要细节UML图的分类静态模型（staticmodel）动态模型（dynamicmodel）静态建模创建并记录一个系统的静态特征反映一个软件系统基础、固定的框架结构创建相关问题域主要元素的视图静态建模包括：

——用例图（usecasediagrams）

——类图（classdiagrams）

——对象图（objectdiagrams）

——组件图（componentdiagrams）

——部署图（deploymentdiagrams）动态建模动态建模用以展示系统的行为动态建模包括：

——时序图（sequencediagrams）

——协作图（collaborationdiagrams）

——状态图（statechartdiagrams）

——活动图（activitydiagrams）其它重要的UML元素包（package）UML的扩展机制

——注释（comments）

——构造型（stereotypes）

——标记值（taggedvalues）

——限制（constraints）核心UML图用例图 展示系统的核心功能及与其交互的用户 用户被称之为“活动者”（Actor） 用例使用椭圆表示 为简化建模过程，用例图可标注优先级AGenericUseCaseDiagram类图表现类的特征类图描述了多个类、接口的特征，以及对象之间的协作与交互由一个或多个矩形区域构成，内容包括：

——类型（类名）

——属性（可选）

——操作（可选）AGenericClassDiagram对象图表现对象的特征对象图展现了多个对象的特征及对象之间的交互AGenericObjectDiagram组件图表现软件组件之间的关系AGenericComponentDiagram部署图表现用于部署软件应用的物理设备信息ADeploymentDiagram时序图捕捉一段时间范围内多个对象之间的交互信息强调消息交互的时间顺序AGenericSequenceDiagram协作图表现一定范围内对象之间协作的信息强调参与信息交流的对象之间的组织结构ACollaborationDiagram状态转换图强调一个对象在不同事件触发时，其内部状态的转变过程AGenericStateTransitionDiagram活动图描述活动的流程AGenericActivityDiagram包引用一组相关实体通常可用于划分类的命名空间包可用于

——命名(Naming) ——成员可见度(Membervisibility) ——导入(Importing) ——继承(Extending) ——泛化(Generalization)UML的扩展机制UML的扩展机制

——注释（comments）

——构造型（stereotypes）

——标记值（taggedvalues）

——限制（constraints）DiagramforUMLExtensionMechanismCheckYourProgress定义UML在OOAD过程中的作用UML的九种基本图形UML的扩展机制Module3:需求与初始化分析学习目标编写系统设计与需求说明书解释信息的收集过程解释领域专家的角色编写问题描述描述定义与维护数据字典的重要性描述分析候选业务对象的过程解释用例图的角色与功能解释为一个用例开发多个场景的过程用例图与活动图的关系学习目标解释风险评估的重要性解释用包划分用例和高层的包标记定义组件图与部署图启动开发过程本章主要解决以下几方面问题：

——初始化系统开发环境

——分析初始工作流

——收集信息

——创建问题域

——创建用例图

——创建相关的组件图与部署图收集信息收集的信息可来源于：

——客户最初的需求说明书

——领域专家

——客户与用户

——管理人员

——市场信息

——以前的项目避免传统的假设你应该避免传统的假设，如：

——用户是幼稚的，开发者了解一切

——需求是一成不变的

——你可以一次就开发出最终的解决方案记住项目是在不断演进的，用户需求会不断变化避免传统的假设做以下工作

——明确用户的需求

——确定你的模型能适应用户需求的变化

——确定你可以更改你的模型领域专家解决特定业务领域问题时，向领域专家咨询领域专家可分为以下几个角色

——行业领域专家

——相关应用领域专家与当前业务领域专家

——相关业务领域专家问题描述文档是否清晰地描述了客户和系统的需求？客户提供信息的重要性使用行业术语语句陈述清晰、准确，不带假设包含项目范围内的细节指明问题域的环境指明已知的限制条件问题域清晰展现与系统相关的区域和问题的范围可以用图形或文本形式说明候选对象与类从问题陈述中挑选问题陈述中出现的名词都是潜在的对象与类数据字典一份用于描述项目中所用词汇的文档从与用户的交流中收集整理存在于整个项目与系统的范围内可在项目过程中不断补充新术语满足公共词汇表的需要避免模棱两可的表达对项目中的所有开发人员来说都是容易使用的需要经常地、细心地控制版本更新创建用例用例表现用户与系统的交互帮助理解系统需求与环境用实线组成的椭圆表示创建用例模型由多个用例组成包含以下组件：

——活动者

——用例

——系统

——泛化与关联关系用例场景用例展现了从用户角度看到的系统功能一个场景对应一个用例场景中不包含假设条件从同一点出发，结束时可不同主要场景必须描述用例中的成功或不成功的途径都应被描述活动图用于展现活动、过程与工作流使用图形的表达方式可用在任何你需要对活动建模的地方活动图包含下列元素

——活动

——判断

——流程的分离

——流程的汇合

——迭代

——对象流

——泳道活动图Swinglaneseparatorforkjoinbranchmerge风险评估项目中的风险需要进行评估用例可作为风险评估的起点高风险用例应当在早期迭代过程中优先开发风险可能来自以下区域：

——需求风险

——技术风险

——技能风险

——资源风险

——政策风险高层次包图UML可使用标记将所有元素打包到一起（类、对象、用例、工件等）标记类似于文件系统中的目录图标有助于降低系统的复杂度可表示包之间的依赖关系使用包有助于：

——从框架上看问题避免涉及过多细节

——可独立地查看某个组成部分

——组成部分的设计可推迟到具体场景中再完成组件图表现系统中的组件及其关系有助于降低系统复杂度使用祖件有助于：

——从框架上看问题避免涉及过多细节

——可独立地查看某个组件

——组件的详细设计可推迟到具体场景中再完成部署图展现硬件设备之间的物理联系可在项目的任意阶段加入当有补充信息时可随时完善节点中可包含组件节点之间的连接（通讯方式）使用协议说明Checkyourprogress开发系统设计与需求说明书以及初始工作流解释信息的收集过程解释领域专家的角色编写问题描述描述定义与维护数据字典的重要性描述分析候选业务对象的过程解释用例图的角色与功能解释为一个用例开发多个场景的过程用例图与活动图的关系Checkyourprogress解释风险评估的重要性解释用例打包和高层的包标记定义组件图与部署图Module4:分析阶段的静态建模学习目标如何在分析阶段鉴别系统所需的对象与类解释系统的静态视图定义动态模型的角色创建对象图与类图定义属性与方法解释类图中关联的概念解释基数性的概念定义复杂关联解释如何通过关联类与引用关联解决复杂关联问题学习目标解释继承、泛化、特化的概念解释多态定义抽象类解释类图中关联的概念解释聚合、组合的概念描述OOAD中“角色名”使用解释类图中扩散的概念解释代理与委托理解分析阶段跟随在需求收集阶段与用例之后在运行期鉴别对象需求定义系统必须完成的工作避免描述设计与实现细节关注系统中的组件理解分析阶段鉴别候选对象与类

——什么是对象之间的联系

——对象与类的责任

——对象如何彼此联系更新数据字典关键抽象从候选对象列表中选取的子列表用于表现一个系统中的核心对象分析每一个候选对象，判断其是否足够重要到关键抽象的层次在UML中表现对象与类在对象模型中表现静态视图的逻辑与物理特征对象模型的两种图

——类图

——对象图类图ClassNameAttributesMethods对象图ObjectNameAttributeValue属性与方法对象的属性定义特征，方法定义行为类的作用就是定义属性与方法此阶段设计类不需要给出过于详细的信息属性的划分

——普通属性

——推导属性关联与链接关联

——类图中表示类之间关系的连线

——连线可水平或垂直

——连线上可注明描述关系的逻辑名称链接

——对象图中表示对象之间关系的连线类之间的关联PersonCarowns对象之间的链接:Carowns:Person关联与链接的方向性Unidirectional（单向关联）Bidirectional（双向关联）PersonCarowns:Person:Carowns关联与多重性多重性展现一个类与另一个类关联时，实例数量上的映射关系在关联线的两侧表示表现运行期的关系CarandEngineClassDiagramCarEngine1Poweredby1PersonandCarClassDiagramPersonCar1owns*UML中对多重性的表示DefiniteValueMultiplicityIndefiniteValueMultiplicityRangeofValuesMultiplicitySetofValuesMultiplicity值的多重性ClassClassClassClass2*5..152,4,6DefinitevaluemultiplicityRangeofvaluesmultiplicitySetofvaluesmultiplicityIndefinitevaluemultiplicity复杂关联多对多的关联关系可通过映射关联类的方式解决PersonandBookClassDiagramPersonBook*Borrows*关联类用于解决复杂关联的技术在分析阶段解决多对多的映射关系关联类通过属性的方式解决类与类的映射PersonandBookClassDiagram

WithAnAssociationClassPersonandBookAssociation

inNormalSyntax限制关联（QualifiedAssociation）解决复杂关联的技术通过分配一个唯一的属性值完成BankandCustomerClassDiagramBankCustomer*bankswith*QualifiedAssociationfor

BankreferringtoaCustomerBankCustomer*bankswithcustRefQualifiedAssociationfor

CustomerreferringtoaBankBankCustomerbankswith*bankCode分析阶段的逻辑关系问题

——一个类的功能需要依赖另外一个类吗？

——依赖的强烈程度如何？分析阶段的逻辑关系本模块讨论的逻辑关系包括：

——继承 泛化（Generalization） 特化（Specialization）

——多态

——关联 聚合 组合

——扩散与委托继承表示类之间如何共享属性与方法单重继承与多重继承UML中如何表示继承继承关系的分析分析继承的两种方式

——泛化

——特化泛化

——从一组已经存在的类中抽取出公共的特征得到一个新类的过程泛化特化当要增加的新类与已存在的类有着相同的结构、功能和目的，但新类需要增加新的属性与方法多态与继承关系紧密多种形式从分析的角度看，多态意味着一个实体的属性可以被分配给已知的类或类型，而这可以在实体的行为方式最终被确定之前完成抽象类一个包含了未实现方法的类。抽象类不能被实例化一个继承了抽象类的类将会继承所有的方法，包括抽象方法一个继承了抽象方法的类将被定义为一个新的抽象类，否则在该类中就应该重写抽象方法并给出具体实现过程子类重写父类方法的过程称为方法覆盖UML中对抽象类的表示抽象类类名用斜体表示抽象方法也用斜体表示，或者在方法后加大扩号，注明{abstract}方法名后的小扩号称为方法的属性列表抽象类的继承结构角色名表示类与类之间交互时扮演的“角色”UML中，角色在关联线的两端表示关联最终将在代码中以引用变量的形式表示，一个类通过引用变量指向另一个类角色名最终以属性名的形式表示带角色名的关联反射关联一个类与自己发生关联的现象称为反射关联对象图中，同种类型的两个对象可以用两个实例来表示类图中，相同类型用一个类来表示反射关联关联按照联系的强弱程度可再分为普通关联、聚合与组合

——关联：厨师使用刀切菜

——聚合：汽车里安装的收音机

——组合：汽车总会有自己的引擎关联关系

聚合关联的一种形式类之间满足“hasa”这样的关系类图中表示聚合组合关联的一种形式，表示两个类之间拥有很强的关系组合关系中，一个实体总是包含了另一个实体，换言之，外部实体将会管理内部实体的生命周期组合的表示形式方法扩散通过聚合或组合来表示的类与类之间方法调用的传递关系当调用一个类中的某个方法时，导致更多类中的方法按某种方式被调用类图中表示方法是可扩散的代理与委托方法扩散中，代理对象与被代理对象没有相同的继承或实现关系时称为委托若代理对象与被代理对象继承了同一个父类或实现了同一个接口，则称为代理CheckyourProgress如何在分析阶段鉴别系统所需的对象与类解释系统的静态视图定义动态模型的角色创建对象图与类图定义属性与方法解释类图中关联的概念解释基数性的概念定义复杂关联解释如何通过关联类与引用关联解决复杂关联问题CheckyourProgress解释继承、泛化、特化的概念解释多态定义抽象类解释类图中关联的概念解释聚合、组合的概念描述OOAD中“角色名”使用解释类图中扩散的概念解释代理与委托Module5:分析阶段的动态建模学习目标解释面向对象中“责任”的概念解释动态建模的概念解释并创建时序图解释并创建协作图解释并创建状态转换图解释并创建活动图创建分析阶段的动态模型在OOAD过程中，动态建模发生两次

——在逻辑分析阶段，确保系统中的每一个操作是可实现的

￭时序图

￭协作图

￭状态图

￭活动图

——在物理设计阶段，具体细化类中的方法 责任在OOAD的术语中，“责任”通常指：

——一个类或类型知道什么（状态）

——一个类或类型能做什么（行为）时序图为一段时间内系统中的某个操作建模一张时序图

——与一个用例或用例场景直接相关

——标示出在过程中所涉及的对象

——标示出在过程中所涉及的所有动作或事件

——标示出在过程中所传递的信息

——标示在每一个动作结束时需要的响应信息

——分析阶段一个用例至少对应一张时序图时序图的基本结构时序图举例协作图时序图中交互过程的另一种表现形式对象之间使用带数字编号的箭头连接以表现信息的流程箭头由动作的发起者指向目标箭头的数字编号表示在场景交互的次序协作图举例状态转换图表示一个对象在调用了一系列方法后自身状态的改变由以下两种元素组成：

——状态

——事件箭头表示状态转换的路径箭头展示了对象在表现具体事件时执行的任务对象不需要贯穿整个系统的生命周期，对象在终止点结束状态转换图举例银行帐户的状态图状态图的阀值条件状态图的动作活动图表现工作流中对象间的连接，以及并发过程中的方法一个活动图对应一个用例一个活动使用椭圆表示，活动与活动之间用连接线按一定顺序连接，连接线可看作触发条件一个活动按连接线的数量可有多个触发条件接收订单用例的活动图CheckYourProgress

解释面向对象中“责任”的概念解释动态建模的概念解释并创建时序图解释并创建协作图解释并创建状态转换图解释并创建活动图Module6:设计原则与模式学习目标解释软件的可扩展性与可维护性解释下列设计原则： “开—闭”原则（OCP） 里氏代换原则（LSP） 依赖倒转原则（DIP） 接口隔离原则（ISP） 组合/聚合复用原则（CARP） 迪米特法则（LoD）解释设计模式的概念和组成元素学习目标区分并理解下列设计模式： 工厂模式 单例模式 组合模式 观察者模式

MVC模式 状态模式面向对象设计中的两个核心问题软件的可维护性软件的可复用性软件的可维护性软件的开发阶段与维护阶段软件难于维护的原因

——过于僵硬

——过于脆弱

——复用率低

——黏度过高软件的可复用性复用的重要性传统的复用

——代码的剪贴复用

——算法的复用

——数据结构的复用可维护性与复用的关系面向对象设计的复用设计目标可扩展性灵活性可插入性设计原则“开—闭”原则（OCP）里氏代换原则（LSP）依赖倒转原则（DIP）接口隔离原则（ISP）组合/聚合复用原则（CARP）迪米特法则（LoD）“开—闭”原则（OCP）“开—闭”原则：一个软件实体应该对扩展开放，对修改关闭如何做到“开—闭”

——抽象化是关键对可变性的封装原则

——可变性不应该散落在代码的很多角落里，而应该被封装到一个对象中

——一种可变性不应当与另外一种可变性混合在一起里氏代换原则（LSP）里氏代换原则：任何基类适用的地方，子类一定也适用从继承的角度实现“开—闭”依赖倒转原则（DIP）依赖倒转原则：要依赖于抽象，不要依赖于实现三种耦合关系

——零耦合

——具体耦合

——抽象耦合针对接口编程接口隔离原则（ISP）接口隔离原则：使用多个专门的接口比使用单一的总接口要好定制服务接口污染组合/聚合复用原则（CARP）组合/聚合复用原则：要尽量使用组合/聚合，而不是使用继承来达到复用目的继承的优点与缺点组合/聚合的解决方案迪米特法则（LoD）迪米特法则也称“最少知识原则”：一个对象或模块应该和其它对象和模块尽量少的通信对耦合问题的解决迪米特法则下的模式

——门面模式

——调停者模式

——前端控制器模式

——业务代表模式

——DAO模式设计模式定义：设计模式用于描述一组对象与类之间的交互以解决某个场景中的设计问题

——通过架构模式提升

——设计模式中的主要元素 模式名 问题 解决方案 结果工厂方法模式问题域：

——你需要获得一组相关产品类的某个实例

——根据请求的不同，可以获得不同的对象解决方案

——创建抽象工厂类，通过抽象工厂定义的抽象方法返回抽象产品

——创建具体工厂类，实现抽象方法返回具体产品工厂方法模式示例工厂方法模式单例模式问题域：

——系统中你需要获得某个类的唯一实例，所有客户端对它的访问都将通过一个公共的访问点获得解决方案：

——创建一个类并使其：（A）定义一个私有的构造器（B）定义一个私有、静态的实例变量指向自己（C）定义一个公有、静态的访问方法用于返回该类的唯一实例单例模式单例模式组合模式问题域：

——你需要描述对象之间整体—部分的关系

——你需要使用同一个接口装配接口下的单纯元素与复合元素解决方案：

——创建一个抽象类作为“树根”，创建一组具体类作为“树叶”，并挑选一个具体类作为容器类保留对其它兄弟节点的引用组合模式组合模式观察者模式问题域：

——当事件发生时，你需要通知一组对象

——当一个对象状态变化时，你需要通知其它对象，但有多少事先无法估计解决方案：

——创建一个抽象的主题类用于维护一组观察者

——当主题类状态变化时，自动通知所有监听的观察者观察者模式观察者模式模型—视图—控制器模式问题域：

——需要显示模型的多个视图，控制器与模型和视图相互独立解决方案：

——减少数据与具体视图的耦合，使得多个视图可以访问相同数据

——运行过程中，使用观察者模式为模型注册相关视图

——使用策略模式，视图可动态分配到控制器对象MVC模式 Model*Encapsulatesapplicationstate*Respondstostatequires*Exposesapplicationfunctionality*Notifiesviewsofchanges View*Rendersthemodels*Requestsupdatesfrommodels*Sendsusergesturestocontroller*Allowscontrollertoselectview Controller*Definesapplicationbehavior*Mapsuseractionstomodelupdates*Selectsviewforresponse*OneforeachfunctionalityMethodinvocationEventsStateQueryChanceNotificationUserGesturesViewSelectionStateChangeMVC模式MVC模式状态模式问题域：

——对象的行为依赖其状态，对象必须根据其状态选择不同的行为方式解决方案：

——主对象称之为Context，它有一个或多个依赖于状态的方法

——为每一个状态创建一个具体的状态类，每个状态类都实现了Context定义的方法文档类的状态图状态模式状态模式state.handleRequest()ConcreteStateAhandleRequest()ConcreteStateBhandleRequest()Contextrequest()StatehandleRequest()+stateCheckyourProgress解释软件的可扩展性与可维护性解释下列设计原则： “开—闭”原则（OCP） 里氏代换原则（LSP） 依赖倒转原则（DIP） 接口隔离原则（ISP） 组合/聚合复用原则（CARP） 迪米特法则（LoD）解释设计模式的概念和组成元素CheckyourProgress区分并理解下列设计模式： 工厂模式 单例模式 组合模式 观察者模式

MVC模式 状态模式Module7:设计阶段的静态建模学习目标为模型中添加设计细节在模型中应用封装的概念定义属性与属性类型解释限制、方法、静态数据及静态方法类的划分定义控制器类与容器类定义用户接口与事件类定义关联类以及在设计阶段如何消除关联类检查并理解关联、聚合、组合关系在编码上的差异解释方向性学习目标解释链接访问方法定义设计阶段的限制关联定义设计阶段的委托解释复杂操作介绍类图中增加新的设计元素到本阶段为止，类图应该具有以下特征：

——结构良好

——完整，包含必要的属性与方法

——没有冗余属性与方法

——内聚

——是对某单一概念的抽象

——与其它类的耦合应该比较松封装Public与private使用封装

——所有的属性定义为private ——提供相应的方法完成对属性的访问，这些方法称为存取方法

——所有的内部方法定义为private，可以定义自己的“工具”方法UML中表示封装EmployeeNameaddressAnalysisDesign<<refines>>AccountnameaddressAnalysisDesign<<refines>>creditdebit设计属性每一个属性都必须定义

——数据类型

——缺省值（如果有）

——限制（如果有）属性的数据类型可以是

——基本类型

——引用类型属性的表示初始值属性限制设计方法寻找一个类的方法：AccessormethodsLinkaccessmethodsManagementmethodsMissingdomainmethodsTestabilityoperationsInverseoperationComplementaryoperationsRecoveryoperationsFutureneeds方法接口方法参数与返回类型可以为以下任意类型：

——boolean ——primitivetype ——reference ——list ——nothing(void)方法接口方法实现UML中没有具体的表示Case工具可以实现使用时序图和协作图可以分析一个方法应有的行为如果实现语言已知，可使用伪代码或真实代码方法实现推导属性可以从已知属性或基本条件推导出来的属性设计阶段，判断推导属性的源使用源来表现属性可以避免重复计算推导属性Employeenameaddress/agederivedattributes静态数据与方法静态数据与方法构造器用于为属性赋一个显式的初始值构造器的形式

——缺省构造器

——空参数构造器

——带参数构造器UML中，没有专门表示构造器的标记，构造器与方法定义在一起构造器类的划分类可以根据其在应用中扮演的角色划分不同类型类在应用中扮演的5个重要角色：

——模型

——控制器

——容器

——接口

——事件处理器通过生命周期划分对象对象的生命周期可以与程序执行的时间一样长或更短对象的生命周期也可以比程序执行的时间更长通过生命周期划分对象对于对象持久化，可以将对象存于程序之外，以下是四种典型的方式

——创建包含相同信息的持久化对象作为应用对象

——对象序列化

——对象模型转化为关系模型

——使用面向对象的数据库，对象的成员可直接存于数据库控制器类控制器类具有以下特征：

——通过类控制对象

——简化应用中类的责任

——通常用于消除类与类之间的直接交互

——减少业务对象之间的耦合控制器类控制器类控制器类容器类包含对象可以扩展或包含一个Vector、LinkedList、Map、array等容器类使用LinkedList的容器类用户接口类用于大多数程序使用代理模式或在程序启动时实例化可以使用观察者模式，但会影响系统性能可放在包中事件处理器可放在用户接口类中事件与事件处理器类事件处理器处理包含信息的事件对象Java技术提供事件处理的框架，如swing/awtUML使用构造型标记你可以定义非GUI的事件事件处理器对象应该在与其交互的业务对象和用户接口对象建立连接时实例化事件处理器类关联类在分析阶段用来解决多对多关联关系，它将两个类之间的多对多转化成三个类之间的两次一对多关系。在两个类之间增加的映射类即关联类关联类通过关联属性分别引用两个实体类消除关联类<<refines>>消除关联类<<refines>>组合关系示例ClassCar{ Engineengine; Car(intengineSize,intnumberOfCyclinders,Stringmake,Stringmodel) { engine=newEngine(engineSize,numberOfCylineders); //othercodehere }}//elsewhereincodeCarcar=newCar(2000,6,“Ford”,“Scorpio”);//endofcode聚合关系示例ClassCar{ Engineengine; Car(Engineengine,Stringmake,Stringmodel) { this.engine=engine; //othercodehere }}//elsewhereincodeEngineengine=newEngine(2000,6);Carcar=newCar(engine,“Ford”,“Scorpio”);//endofcode关联关系示例ClassCar{ Personperson; add(Personperson) { this.person=person; }}//elsewhereincodeCarcar=newCar(“Ford”,“Scorpio”);Personperson=newPerson(“Homer”,“Simpson”);car.add(person);//endofcode关联的方向性用来表示关联的方向在分析阶段，所有的关联都被考虑成双向的设计阶段，需要考虑原先的双向关联是否有必要双向关联的问题单向关联可以减少连接中的问题，若都能满足业务需求，尽量使用单向关联关联的方向性BidirectionalAssociationUnidirectionAssociationUnidirectionAssociation消除多对多关联本阶段首先确定是否有多对多关联的必要一般做法是在多对多关联中插入类消除多对多关联连接访问方法表示用于get/set/add/remove对象连接的方法如果多重性为1，可以设计get/set方法，或者使用构造器传引用如果多重性为M，可以选择数组（较少时）或集合连接访问方法<<refinement>>限制关联表示使用某个变量来查找一个连接对象使用限制关联

——需要有方法支持

——尽量使查找过程优化

——可以有普通的set,get,add,remove方法限制关联CompanyemployeeID<<refinement>>委托表示一个操作传递给另一个对象委托类可以是一个具体类，或者是一个抽象类通过具体子类来完成使用多态方式可以在不修改现有类结构的基础上增加新类型委托示例复杂操作CheckyourProgress为模型中添加设计细节在模型中应用封装的概念定义属性与属性类型解释限制、方法、静态数据及静态方法类的划分定义控制器类与容器类定义用户接口与事件类定义关联类以及在设计阶段如何消除关联类检查并理解关联、聚合、组合关系在编码上的差异解释方向性CheckyourProgress解释链接访问方法定义设计阶段的限制关联定义设计阶段的委托解释复杂操作Module8:设计阶段的动态建模学习目标为分析阶段创建的时序图增加设计细节为分析阶段创建的协作图增加设计细节为分析阶段创建的状态转换图增加设计细节为分析阶段创建的活动图增加设计细节创建设计阶段的动态模型保证每一个用例场景满足了最初的目的注意前期设计中的缺陷验证已存在的类，找